View GT-64111_1049923.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

GT-64111 system controller for rc4640, rm523x and vr4300 cpus product preview revision 1.1 feb 4, 1999 please contact galileo technology for possible updates before finalizing a design. features www.galileot.com support@galileot.com tel: +1-408.367.1400 fax: +1-408.367.1401 ? integrated pci system controller for high-performance cost sensitive embedded applications ? support the following 32-bit bus cpus: - idt rc4640 and rc4650 (in 32-bit mode) - qed rm523x - nec/toshiba vr4300 ? up to 66mhz cpu bus frequency ? 64 byte cpu write posting buffer - 32-bit wide, 16 levels deep - accepts cpu writes with zero wait-states ? edo and fast page mode dram controller - 512mb address space - supports dram bank interleaving - 256kb-16mb device depth - 1- 4 banks supported - 32-bit or 64-bit data width - parity supported - zero wait-state interleaved burst accesses at 66mhz ? device controller - 5 chip selects - programmable timing for each chip select - supports many types of standard memory and i/o devices - up to 160mb address space - optional external wait-state support - 8-,16-,32- and 64-bit width device support - support for boot roms - parity supported for devices ? four channel dma controller - chaining via linked-lists of records - byte alignment on source and destination - transfers through 32-byte internal fifo - moves data between pci, memory, and devices ? high-performance 32-bit universal pci 2.1 interface - 96-bytes of posted write and read prefetch buffers - 32-bit pci master and target operations - pci bus speed of up to 66mhz with no wait states - operates either synchronous or asynchronous to cpu clock - burst transfers used for efficient data movement - doorbell interrupts provided between cpu and pci - supports flexible byte swapping through pci inter- face - synchronization barrier support - pci configuration registers can be accessed from both cpu and pci side - support for both 5v and 3.3v operation ? host to pci bridge - translates cpu cycles into pci i/o or memory cycles - generates pci configuration, interrupt acknowl- edge, and special cycles on pci bus ? pci to main memory bridge - supports fast back-to-back transactions - supports memory and i/o transactions to internal configuration registers - supports locked operations ? three 24-bit wide and one 32-bit wide timer/counters ? plug and play support - pc compatible configuration registers - pci configuration header can be loaded from boot prom - pci configuration registers are accessed from both cpu and pci bus ? 3.3v supply voltage (pci and peripherals) - 5v tolerant i/os ? 208 pqfp GT-64111 32-bit/66mhz sysad cpu 32-bit/66mhz pci bus network other . . . scsi 32-bit address/data bus address/control flash i/o . . . sdram
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 2 revision 1.0
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 table of contents 1. overview................................................................................................................... ....................... 7 1.1 cpu bus interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 1.2 dram and device interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 1.3 pci interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 1.4 dma engines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 1.5 cpus supported. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 1.6 block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 2. pin information.............................................................................................................. ..................... 10 2.1 logic symbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 2.2 pin assignment table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 3. cpu/local master interface ................................................................................................... ........... 15 3.1 cpu/local master interface signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 3.2 sysad and syscmd buses (9-bit syscmd mode) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 3.2.1 sysad read protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2.2 sysad write protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.3 4300 bus mode support (5-bit syscmd mode) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 3.4 operation of wrrdy* and the internal write posting queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 3.5 mips write modes and write patterns supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 3.6 cpu/local master interface endianess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 3.7 burst order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22 3.8 cpu/local master interface restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22 4. address space decoding....................................................................................................... ........... 23 4.1 two stage decoding process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 4.1.1 cpu/local master side decoding process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.2 pci side decoding process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 4.3 disabling the device decoders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 4.4 dma unit address decoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 4.5 address space decoding errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29 4.6 default memory map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29 5. memory controller ............................................................................................................ ................. 31 5.1 dram controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31 5.1.1 dram refresh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.1.2 assymetrically ras*/cas* addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.1.3 dadr[11]/ads* function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.1.4 programmable dram timing parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.1.5 dram bank width and location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.1.6 dram performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.2 device controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35 5.2.1 turnoff, bits [2:0] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.2.2 acctofirst, bits [6:3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.2.3 acctonext, bits [10:7]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.2.4 adstowr, bits[13:11] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.2.5 wractive, bits[16:14] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.2.6 wrhigh, bits[19:17] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.2.7 burst transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.2.8 packing and unpacking data and burst support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.2.9 destructive reads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.2.10 ready* support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.2.11 device bank width and location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 4 revision 1.0 5.2.12 sysad to ad addressing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.3 data latches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.3.1 enabling latch control signals on read transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44 5.4 parity checking support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.5 addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.6 memory interface restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 6. pci bus ...................................................................................................................... ......................... 47 6.1 pci master operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 6.1.1 pci master cpu/local master address space decode and translation . . . . . . . . . . . . . . . . . . . . . . . 47 6.1.2 pci master cpu/local master byte swapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 6.1.3 pci master fifos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 6.1.4 pci master dma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.1.5 pci master retry counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.1.6 cache line size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.2 pci target interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.2.1 pci target fifos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 6.2.2 pci target address space decode and byte swapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.2.3 tweaking the performance of the target interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 6.3 pci synchronization barriers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 6.4 pci master configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 6.4.1 special cycles and interrupt acknowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.5 target configuration and plug and play . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.5.1 plug and play base address register sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.5.2 multi-function device, swap bars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 6.5.3 pci autoconfiguration at reset. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 6.5.4 expansion rom functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 6.6 pci parity support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 6.7 pci bus/device bus/cpu/local master clock synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.8 66mhz capability bit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.9 universal pci vio pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.10 pci interface restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.10.1 master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.10.2 slave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.10.3 master and slave. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 7. dma controller ............................................................................................................... ................... 56 7.1 dma channel registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 7.2 dma channel control register (0x840 - 0x84c). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 7.2.1 addcontrol[1:0], GT-64111-p-1 only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 7.2.2 srcdir, bits[3:2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 7.2.3 destdir, bits[5:4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 7.2.4 dattranslim, bits[8:6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 7.2.5 chainmod, bit 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 7.2.6 intmode, bit 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 7.2.7 transmod, bit 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 7.2.8 chanen, bit 12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 7.2.9 fetnexrec, bit 13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 7.2.10 dmaactst, bit 14 (read only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 7.3 restarting a disabled channel (previously active) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 7.4 reprogramming an active channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 7.5 arbitration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 7.6 dmareq[3:0]* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 7.7 dmaack[3:0]* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 7.8 design information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 7.8.1 dma in demand mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 7.8.2 dma in block mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 7.8.3 non-chain mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 7.8.4 chain mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 7.8.5 dynamic dma chaining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 7.9 dma restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62 8. timer/counters ............................................................................................................... ................... 64 9. interrupt controller ......................................................................................................... ................... 65 10. reset configuration......................................................................................................... .................. 66 11. connecting the memory controller to dram and devices............................................................ 69 11.1 workin g without data latches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69 11.2 workin g with data latches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70 11.2.1 64-bit dram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 11.2.2 32-bit dram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 11.2.3 64-bit devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 11.2.4 32-bit or less devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 12. big and little endian ....................................................................................................... .................. 74 12.1 back g round . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74 12.1.1 bit 12 of the cpu/local master interface configuration register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 12.1.2 bit 0 of the pci internal command register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 12.2 confi g urin g a s y stem for bi g and little endian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74 13. using the GT-64111 without the cpu/local master interface ....................................................... 76 14. using the GT-64111 without the pci interface................................................................................ 76 15. applications: system configurations ............................................................................... 77 15.1 minimal s y stem confi g uration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77 15.2 t y pical s y stem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78 15.3 interface to as y nchronous devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79 15.4 interface to dram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80 15.5 a s y stem with parit y . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81 16. designing for compatibility with the gt-64011 .............................................................................. 8 3 16.1 major hardware differences between the gt-64011 and GT-64111 . . . . . . . . . . . . . . . . . . . . . . . . . . . .83 16.2 all differences between the gt-64011 and GT-64111 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83 17. register tables ............................................................................................................. .............. 85 17.1 access to on-chip pci confi g uration space re g isters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85 17.2 re g ister map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85 17.3 cpu/local master interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90 17.4 cpu/local master decode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90 17.5 device decode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93 17.6 dram confi g uration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96 17.7 dram parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96 17.8 device parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98 17.9 dma record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99 17.10 dma channel control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102 17.11 arbiter control, offset: 0x860 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104 17.12 timer / counter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104 17.13 pci internal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106 17.14 interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .110 17.15 pci confi g uration re g isters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112 17.15.1 function 1 configuration registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 6 revision 1.0 18. pinout table, 208 pin pqfp (sorted by number)..................................................................... 117 19. dc characteristics - preliminary/subject to change .............................................. 119 19.1 absolute maximum ratings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 19.2 recommended operating conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 19.3 dc electrical characteristics over operating range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 19.4 thermal data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 20. ac timing - targets/subject to change ........................................................................... 122 20.1 tclk/pclk restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 21. functional waveforms ........................................................................................................ ............ 128 22. packaging ................................................................................................................... ...................... 129 23. revision history ............................................................................................................ .................. 130
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 1. overview the GT-64111 provides a single-chip solution for designers building systems around 32-bit bus/64-bit internal mips embedded processors. the architecture of the GT-64111 supports several system implementations for different appli- cations and cost/performance points. it is possible to design a powerful system with minimal glue logic, or add com- modity logic (controlled by the GT-64111) for differentiated system architectures that attain higher performance. the GT-64111 has a three bus architecture: ? a 32-bit interface to the cpu bus (sysad bus) ? a 32-bit interface to the memory and device subsystem. ? a 32-bit interface to the pci bus. the three buses are de-coupled from each other in most accesses, enabling concurrent operation of the cpu bus, pci devices, and accesses to memory. for example, the cpu bus can write to the on-chip write buffer, a dma agent can move data from dram to its own buffers, and a pci device can write into an on-chip fifo, all simultaneously. 1.1 cpu bus interface the GT-64111 sysad bus allows the cpu and other local bus masters to access the pci and memory/device buses. the sysad bus protocol supports byte and 32-bit word operations with burst lengths up to 8 words (sub-word, 2 word, and 4 word transfers are also supported.) with a maximum frequency of 66mhz, the cpu can transfer in excess of 150 mbytes/sec. the GT-64111 can automatically determine if the attached mips processor is using the 8-bit syscmd protocol (rc4640, rm523x) or the 5-bit syscmd protocol (vr4300). 1.2 dram and device interface the GT-64111 has a flexible dram controller that supports edo as well as standard page mode drams. with 45ns standard drams, the GT-64111 can return data at 8-2-2-2-2-2-2-2 1 clocks with 32-bit drams and at 8-1-1-1-1-1-1-1 clocks with 64-bit interleaved drams to the cpu bus- at 66mhz local bus speed. (in wait-state nomenclature this equates to 5-1-1-1-1-1-1-1 and 5-0-0-0-0-0-0-0.) the dram controller supports different depth devices in each bank. note: the performance acheived in interleave mode is equivalent to that possible with sdram. furthermore, edo does not have the granularity/memory waste issues associated with sdram (i.e. it is easy to build the smaller arrays required in many systems.) the GT-64111 memory controller supports different types of memory and i/o devices. it has the control signals and the timing programmability to support devices such as flash, eproms, srams, fifos, and i/o controllers. device widths from 8-bits to 64-bits are supported. parity generation and checking is supported externally and is optional for each bank of dram or any other device on the memory bus. 1.3 pci interface the GT-64111 interfaces directly with the pci bus. the GT-64111 can be either a master initiating a pci bus operation, or a target responding to a pci bus operation. the GT-64111 incorporates 96-bytes of posted write and read prefetch buffers for efficient data transfer between the cpu bus/dma to pci, and pci to main memory. the GT-64111 becomes a pci bus master when the cpu bus or the internal dma engine initiates a bus cycle to a pci device. the following pci bus cycles are supported: memory read/write, interrupt acknowledge, special, i/o read/ write, or configuration read/write. the GT-64111 acts as a target when a pci device initiates a memory access (or an i/o access in the case of internal registers). it responds to all memory read/write accesses, as well as to all configuration and i/o cycles in the case of internal registers. the GT-64111 contains the required pci configuration registers. all internal registers, including the pci configuration 1. note that galileo uses total clock nomenclature and not wait-state nomenclature. this means that 8-1-1-1... means 8 cloc ks to the first data, 1 clock for each additional data (zero wait-states).
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 8 revision 1.0 registers, can be accessed from both the cpu bus and the pci bus. the GT-64111 configuration register set is pc plug and play compatible. the pci interface can operate up to 66mhz and is universal pci compatible (3.3v/5v). 1.4 dma engines the GT-64111 incorporates four high performance dma engines. each dma engine has the capability to transfer data between pci devices, between pci devices and main memory, or between devices residing on the device/memory bus. the dma uses an internal 32-byte fifo for temporary storage of dma data. source and destination addresses can be non-aligned on any byte address boundary. the dma channels can be programmed by the cpu bus or by pci masters, or without cpu bus intervention via a linked list of records that is loaded by the dma controller into the chan- nels working set when a dma transaction ends. the dma supports increment/decrement/hold on source and destina- tion addresses independently. 1.5 cpus supported the GT-64111 can be used with the following processors: ? integrated device technologys (www.idt.com) rc4640 and rc4650 (in 32-bit bus mode) ? quantum effect designs (www.qedinc.com) rm523x ? nec and toshiba vr4300 1.6 block diagram figure 1, below, shows a simplified block diagram of the GT-64111.
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 figure 1: GT-64111 internal block diagram address data data address address 16 x 32 write buffer mux m u x m u x mux 4x32 address buffer 8x32 fifo 8x32 fifo 8x32 fifo 8x32 fifo address data data processor unit dma unit memory unit pci slave pci master dadr ad sysad 32 32 32 dram control 12 32 32 32 32 32 pci ad inter-unit buses
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 10 revision 1.0 2. pin information 2.1 logic symbol validout* validin* wrrdy* release* sysad syscmd[8:0] [31:0] tclk interrupt* rst* pclk req* gnt* perr* serr* lock* devsel* stop* frame* par trdy* irdy* pad[31:0] cbe[3:0]* dwr* ras[3:0]* ad[31:28]/cs[3:0]* oeo* oee* oeb ale idsel ecas[3:0]* ocas[3:0]* leo dram dma pci interface cpu/local interface 32 4 32 9 int* dadr[6:4]/ewr[3:1]* dadr[10:7]/owr[3:0]* ad[27:24]/dmaack[3:0]* 4 22 cstiming* lee leadro dmareq[3]* dmareq[1]*/parerr* 3 4 4 4 dadr[11]/ads* ad[23:2] local device bus latch control GT-64111 ad[0]/bootcs* ad[1]/ devrw* leadre/dmareq[2]* dadr[0]/badr[0] 4 4 & devices dmareq[0]*/ready* dadr[1]/badr[1] dadr[2]/badr[2] dadr[3]/ewr[0] master vio
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 2.2 pin assignment table pin name i/o description cpu/local master interface release* i release interface: signals to the GT-64111 that the cpu/local master has released the sysad and syscmd buses for completion of a read request. wrrdy* o write ready: the GT-64111 signals that it can accept a cpu/local master write request (i.e. there is room in the write posting fifo.) validin* o valid input: the GT-64111 signals that it is driving valid data on the sysad bus, and a valid data identifier on the syscmd bus. validout* i valid output: signals that the cpu/local master is driving valid address or data on the sysad bus and a valid command or data identifier on the syscmd bus. sysad[31:0] i/o system address/data bus: a 32-bit address and data bus for communication between the cpu/local master and GT-64111. syscmd[8:0] i/o system command/data identifier bus: a 9-bit bus for command and data identifier transmission between the cpu/local master and GT-64111. only bits syscmd[4:0] are used when supporting the 4300 bus protocol. interrupt* i/o interrupt: an or of all the internal interrupt sources on the GT-64111. this pin is also sampled as an input at reset for configuration purposes. tclk i clock: the input clock to the GT-64111 (up to 66mhz). tclk is used for both the sysad and device interface. tclk must be driven for all applications, including those that do not use the cpu/local master bus. pci interface pclk i pci clock: this pin provides the timing for the pci transactions. the pci clock range is between 0 and 66mhz. the pclk frequency must be lower than tclk by at least 1 mhz. please see ac timing specifications for more information. rst* i reset: resets the GT-64111 to its initial state. this signal must be asserted for at least 10 pci clock cycles. when in the reset state, all pci output pins are put into tristate and all open drain signals are floated. pad[31:0] i/o pci address/data: 32-bit multiplexed pci address and data lines. during the first clock of the transaction, pad[31:0] contains a physical byte address (32 bits). during subse- quent clock cycles, pad[31:0] contains data. cbe[3:0]* i/o pci bus command/byte enable: during the address phase of the transaction, cbe[3:0]* provide the pci bus command. during the data phase, these lines provide the byte enables. par i/o parity: calculated by the GT-64111 as an even parity bit for the pad[31:0] and cbe[3:0]* lines. frame* i/o frame: asserted by the GT-64111 to indicate the beginning and duration of a master transaction. frame* asserts to indicate the beginning of the cycle. while frame* is asserted, data transfer continues. frame* deasserts to indicate that the next data phase is the final data phase transaction. frame* is monitored by the GT-64111 when it acts as a target. irdy* i/o initiator ready: indicates the bus masters ability to complete the current data phase of the transaction. a data phase is completed on any clock when both trdy* and irdy* are asserted. wait cycles are inserted until trdy* and irdy* are asserted together. trdy* i/o target ready: indicates the target agents ability to complete the current data phase of the transaction. a data phase is completed on any clock when both trdy* and irdy* are asserted. wait cycles are inserted until trdy* and irdy* are asserted together.
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 12 revision 1.0 stop* i/o stop: indicates that the current target is requesting the bus master to stop the current transaction. as a master, the GT-64111 responds to the assertion of stop* by discon- necting, retrying or aborting. as a target, the GT-64111 asserts stop* to retry or discon- nect. lock* i lock: indicates an atomic operation that may require multiple transactions to complete. when the GT-64111 is a pci target, lock* is sampled on the rising edge of the pclk when frame* is asserted. if lock* is sampled asserted, the GT-64111 enters into a locked state and remains in this state until lock* is sampled deasserted on the follow- ing rising edge of pclk, when frame* is sampled asserted. idsel i initialization device select: asserted to act as a chip select during pci configuration read and write transactions. devsel* i/o device select: asserted by the target of the current access. when the GT-64111 is bus master, it expects the target to assert devsel* within 5 bus cycles, confirming the access. if the target does not assert devsel* within the required bus cycles, the gt- 64111 aborts the cycle. as a target, when the GT-64111 recognizes its transaction, it asserts devsel* in a medium speed (two cycles after the assertion of frame*). req* o bus request: asserted by the GT-64111 to indicate to the pci bus arbiter that it requires use of the pci bus. gnt* i bus grant: indicates to the GT-64111 that access to the pci bus is granted. perr* i/o parity error: asserted when a data parity error is detected. serr* o system error: asserted when a serious system error (not necessarily a pci error) is detected. the GT-64111 asserts the serr* two cycles after the failing address. this out- put features an open-drain driver. int* o interrupt request: asserted by the GT-64111 when one of the unmasked internal inter- rupt sources is asserted. this output features an open-drain driver. vio i pci voltage sense: this pin is used to detect the signalling volatge level of the pci bus (5v or 3.3v). note: this pin was vref on the gt-64011 device. dram & devices dwr* o dram write: low when the GT-64111 writes to the dram. dadr[0]/badr[0] o dram address 0 / burst address 0: this pin has two functions. in an access to a dram bank, this pin functions as a dram address bit. in write and read accesses from devices that are 8-bit wide, this pin functions as byte address 0 in the packing process of data into 64-bits. in accesses to a word wide (32-bit) device, this bit functions as address 0 in a burst access (equivalent to sysad[2]). not used for 16/64 bit devices. dadr[1]/badr[1] o dram address [1] / burst address [1]: in dram accesses, this pin functions as an address bit. in read accesses to devices that are 8-, or 16-bit wide, badr[2:1] function as a half word address in the packing process of data into 64 bits. in accesses to a 32- bit bank, badr[2:1] function as part of the (two msb) burst address bits of an address into an eight word line or when packing/unpacking a 64-bit access (equivalent to sysad[4:3]). in accesses to a 64-bit bank, badr[2:1] function as the two burst address bits of a four double word line (equivalent to sysad[4:3]). pin name i/o description
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 dadr[2]/badr[2]/ eromen* o dram address [2] / burst address [2]: in dram accesses, this pin functions as an address bit. in read access to devices that are 8- or 16-bit wide, badr[2:1] function as a half word address in the packing process of data into 64 bits. in accesses to a 32-bit bank, badr[2:1] function as part of the (two msb) burst address bits of an address into an eight word line or when packing/unpacking a 64-bit access (equivalent to sysad[4:3]). in accesses to a 64-bit bank, badr[2:1] function as the two burst address bits of a four double word line (equivalent to sysad[4:3]). this pin is sampled at reset to determine if the pci expansion rom base address register is enabled. dadr[3]/ewr[0]* o dram address [3] / even bank byte write [0]: in dram accesses this pin functions as dram address. in device writes it functions as a byte write enable indication to the even bank byte 0. dadr[6:4]/ ewr[3:1]* i/o dram address [6:4] / even bank byte write [3:1]: in dram accesses these pins function as dram address. in device writes, they function as byte write enable indica- tions to the even bank bytes [3:1]. these pins are sampled as inputs at reset for config- uration purposes. dadr[10:7]/ owr[3:0]* i/o dram address [10:7] / odd bank byte write [3:0]: in dram accesses these pins function as dram address. in device writes, they function as byte write enable indica- tions to the odd bank bytes [3:0]. these pins are sampled as inputs at reset for configu- ration purposes. dadr[11]/ads* i/o dram address [11] / address strobe: the default state of dadr[11]/ads* is to func- tion only as dadr[11]. optionally, this pin is software configurable to only behave as ads* via bit 17 of the dram configuration register. when this pin functions as ads*, it is an active low address data strobe which indicates the beginning of a device trans- action. this pin is sampled as an input at reset for configuration purposes. ras[3:0]* o row address select: supports four banks of dram. the dram banks can be 32-(36- ) bit or 64-(72-) bit wide. ecas[3:0]* o even column address select: supports byte writes/reads to the even bank of the dram (when interleaved.) if the bank is not interleaved, ecas[3:0]* is the same as ocas[3:0]*. ocas[3:0]* o odd column address select: supports byte writes/reads to the odd bank of the dram (when interleaved.) if the bank is not interleaved, ocas[3:0]* is the same as ecas[3:0]*. local ad bus ad[31:28]/ cs[3:0]* i/o data [31:28] / chip select [3:0]: in the data phase, these pins function as data bits [31:28]. in the address phase, device chip selects are valid (and should be latched). the chip selects need to be qualified with the cstiming* signal. latching is done via ale. cs3* is also used to indicate an access to the expansion rom from the pci bus inter- face. ad[27:24]/ dmaack[3:0]* i/o data [27:24] / dma acknowledge[3:0]: in the data phase, these pins function as data bits [27:24]. in the address phase, dma acknowledges are valid (and should be latched). they need to be qualified with the cstiming* signal. latching is done via ale. ad[23:2] i/o address/data[23:2]: multiplexed address and data bus to the dram (data only) and the devices (address and data). pin name i/o description
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 14 revision 1.0 ad[1]/devrw* i/o data [1] / device read-write: in the data phase it is data bit 1. in the address phase, it indicates if an access to a device is a read (1) or a write (0). latching is done via ale. ad[0]/bootcs* i/o data [0]/ boot chip select: in the data phase it is data bit 0. in the address phase, it is the boot device chip select. latching is done via ale. cstiming* o chip select timing: active for the number of cycles that the device that is currently being accessed was programmed to. used to qualify the cs[3:0]*, bootcs and the dmaack[3:0]* signals. latch control ale o address latch enable: used to latch the address, bootcs*, cs[3:0]*, devrw* and dmaack[3:0]* from the ad bus. leo o latch enable odd: used to latch data to or from the odd bank devices. lee o latch enable even: used to latch data to or from the even bank devices. oeo* o output enable odd: output data from the latch of the odd bank to the ad bus. oee* o output enable even: output data from the latch of the even bank to the ad bus. oeb o output enable write: output data from the latch of the ad bus to the memory bus. this signal is only active during writes to dram or devices, and its polarity is program- mable at reset. leadro o latch enable address odd: used to latch the dram address and device burst address of the odd bank. leadre/ dmareq[2]* i/o latch enable address even / dma request: multiplexed signal that can be used to latch the dram address and device address of the even bank or, as a dma request indication by an external device. its function is designated at reset. dma dmareq[3]*/ autoload* i dma request[3]: dma request indication by an external device. this pin is sampled on rst* to enable auto-load mode of pci configuration registers. 0 - auto-load mode enabled 1 - auto-load mode disabled dmareq[1]*/ parerr* i dma request [1] / dma parity error: dma request indication by an external device or parity error indication by external logic. the function of this pin is programmable at reset. dmareq[0]*/ ready* i dma request [0] / ready: this pin has two functions: it serves as a dma request indi- cation by an external device, or as a cycle extender (when inactive during a device access, an access will extend until ready* is asserted). the function of this pin is pro- grammable at reset. pin name i/o description
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 3. cpu/local master interface the GT-64111 sysad bus interface allows the cpu/local master to gain access to the GT-64111s internal registers, pci interface and the memory/device bus (ad bus). the sysad bus supports accesses from one to 32 bytes in length. the sysad bus on the GT-64111 is a slave-only interface; the GT-64111 will never master the sysad bus. 3.1 cpu/local master interface signals the cpu/local master interface incorporates the following signals: ? sysad[31:0] - master address/data. this bus transfers multiplexed address/data. ? syscmd[8:0] - master port command. the syscmd bus transfers information about the access (read/write, size) and the data identifier (good/bad, last word.) only syscmd[4:0] are used in vr4300 mode. ? validout* - indicates that the cpu/local master is driving valid address/data/command on the cpu/local mas- ter bus. ? validin* - indicates that the GT-64111 is driving valid data/data identifier on the cpu/local master bus. ? wrrdy* - indicates that the GT-64111 is capable of accepting a write transaction up to 8 words in length. ? release* - indicates to the GT-64111 that the cpu/local master will not drive the sysad after the current clock cycle (i.e. the cpu/local master is floating the sysad and syscmd bus for completion of a read.) the sysad bus is synchronous with respect to tclk and is locked with respect to the ad bus. the sysad may be asynchronous with respect to the pci bus, or locked to the pci bus for lower synchronization latency. 3.2 sysad and syscmd buses (9-bit syscmd mode) the sysad and syscmd bus protocol implemented by the GT-64111 is completely compatible with the 32-bit orion bus protocol used by the idt r4640 and r4650 processors. the GT-64111 extends this protocol to support bursts less than 8 32-bit words. these extensions can be used by dma engines on the sysad bus for more efficient use of the interface. the sysad[31:0] bus is a 32-bit multiplexed address/data bus. the cpu/local master drives address for a single cycle then either drives data (for a write) or floats the bus is anticipation of returned data (for a read.) the syscmd[8:0] bus conveys information about the transaction such as the direction (read/write), the size (byte, short, word, multi-word) and the status of the data (good/bad/last.) syscmd is driven by the cpu/local master during the address phase of a transaction (with direction/size information) and for the duration of a write (with good/bad/last information.) the GT-64111 drives syscmd during the data phase of read transactions. the encodings for syscmd[8:0] are shown in the tables below. note that many encodings are not defined; these encodings are reserved and must not be used. a summary of bit usage is shown below. table 1. syscmd bit summary syscmd bit function syscmd[8] 0 = transaction information (read/write/size) 1 = data information (good/bad/last) syscmd[7] indicates last data/not last data during data cycles. must be 0 for address cycles. syscmd[6] 0 = read transaction (during address cycles) 1 = write transaction (during address cycles) must be 0 for data cycles. syscmd[5] indicates error status for data cycles. must be 0 for address cycles.
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 16 revision 1.0 1. x denotes dont care but x signals must be driven to a valid 0/1. 1. x denotes dont care but x signals are driven to a valid 0/1 by GT-64111. syscmd[4] cpu mode select 0 - vr4300 mode 1 - r4600 mode syscmd[3:0] encoded to indicate size of the transfer table 2. address phase syscmd[8:0] encodings (driven by cpu/local master) syscmd[8:0] encoding 1 command mnemonic command description 8 7 6 5 4 3 2 1 0 000011000 rdbyte read a single byte 000011001 rdshort read 16 bits 000011010 rdtribyte read 3 bytes 000011011 rdword read 4 bytes (single word) 0000111xx rd2words read 2 words (8 bytes) in a burst 000010xx0 rd4words read 4 words (16 bytes) in a burst 000010xx1 rd8words read 8 words (32 bytes) in a burst 001011000 wrbyte write a single byte 001011001 wrshort write 16 bits 001011010 wrtribyte write 3 bytes 001011011 wrword write 4 bytes (single word) 0010111xx wr2words write 2 words (8 bytes) in a burst 001010xx0 wr4words write 4 words (16 bytes) in a burst 001010xx1 wr8words write 8 words (32 bytes) in a burst table 3. data identifier syscmd[8:0] encodings (driven by GT-64111) syscmd[8:0] encoding 1 command mnemonic command description 8 7 6 5 4 3 2 1 0 1 0 0exxxxx reod indicates last valid data in a burst e = 0 data is good e = 1 data is erroneous 1 1 0exxxxx rd indicates valid data within a burst e = 0 data is good e = 1 data is erroneous table 1. syscmd bit summary syscmd bit function
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 3.2.1 sysad read protocol sysad reads occur in three phases: ? the address phase in which address information is driven on the sysad bus and command information is driven on syscmd. ? the mid-burst data phase during which the GT-64111 drives data on the sysad bus and a data identifier on syscmd. the mid-burst data phase is entered between the address phase and the last data of the burst. ? the last data phase of the burst is when the GT-64111 drives data on the sysad bus and a read end-of-data (reod) data identifier on syscmd. the address phase for all transactions begin with the assertion of validout* to the GT-64111. valid address and com- mand information must be present on sysad and syscmd during this phase. release* must also be asserted to the GT-64111 to indicate that the cpu/local master is releasing mastership of the sysad/syscmd buses to the GT-64111 for completion of the read. validout* is deasserted at the end of the address phase since the cpu/local master is no longer driving information on sysad/syscmd. for transactions longer than 32 bits, the mid-burst data phase is entered next. the GT-64111 will drive valid data on sysad, a valid data identifier (mnemonic = rd) on syscmd, and will assert validin* to qualify the sysad and syscmd buses (see figure 2). the last data phase of the read burst is differentiated from the mid-burst state by the reod data identifier driven on the syscmd bus. the last data phase of the burst is also entered for the datum returned for a single word, or sub-word, read. on the clock cycle following reod, the GT-64111 floats the sysad and syscmd buses, returning ownership to the cpu/local master. figure 2: single word read through cpu/local master interface 1. x denotes dont care but x signals are driven to a valid 0/1. table 4. cpu/local master data identifier syscmd[8:0] encodings (driven by cpu/local master) syscmd[8:0] encoding 1 command mnemonic command description 8 7 6 5 4 3 2 1 0 1 0 1exxxxx weod indicates last valid data in a burst e = 0 data is good e = 1 data is erroneous 1 1 1exxxxx wd indicates valid data within a burst e = 0 data is good e = 1 data is erroneous addr rdword data reod tclk validout* sysad[31:0] syscmd[8:0] release* validin*
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 18 revision 1.0 figure 3: four word burst read through cpu/local master interface 3.2.2 sysad write protocol cpu/local master writes occur in three phases: ? the address phase in which address information is driven on the sysad bus and command information is driven on syscmd. ? the mid-burst write data phase during which the cpu/local master drives data on the sysad bus and a write data identifier (mnemonic = wd) on syscmd. the mid-burst write data phase is entered between the address phase and the last data phase of the write burst. ? the last data phase of the write burst is when the cpu/local master drives data on the sysad bus and a write end-of-data (weod) data identifier on syscmd. the address phase for write transactions begin with the assertion of validout* to the GT-64111. valid address and command information must be present on sysad and syscmd during this phase. release* remains high for write transactions since the cpu/local master is not relinquishing ownership of the bus. validout* is remains asserted throughout a write transaction as the cpu/local master always driving valid information on sysad/syscmd. for transactions longer than 32 bits, the mid-burst data write phase is entered next. the cpu/local master drives valid data on sysad, a valid write data identifier (mnemonic = wd) on syscmd (see figure 4). figure 4: cpu/local master burst write addr rd4words data 1 rd data 2 data 3 data 4 rd rd reod wait state tclk validout* sysad[31:0] syscmd[8:0] release* validin* data should be sampled by cpu/local master here mid-burst data read phase address phase last data phase of burst addr wr4word data 1 wd data 2 data 3 data 4 weod tclk validout* wrrdy* sysad[31:0] syscmd[8:0] release* validin* mid-burst data write phase address phase last data phase of the burst
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 the last data phase of the write burst is differentiated by from the mid-burst state by the weod data identifier driven on the syscmd bus. the last data phase of the burst is also entered for the datum written for a single word, or sub-word, write. on the clock cycle following weod, the GT-64111 returns to the idle state. note: cpu/local master writes cannot be issued as long as wrrdy* is deasserted (high). if wrrdy* is high and an cpu/local master write is attempted, data from previous write cycles may be corrupted (see section 3.4.) note that all mips compliant processors follow this protocol, it is only dma engines on the sysad bus that need to be concerned with sampling wrrdy* before initiating a write. 3.3 4300 bus mode support (5-bit syscmd mode) the GT-64111 can automatically detect (during the first read transaction) when a 4300 bus compatible processor is attached. the 4300 uses a 5-bit syscmd bus encoding that is similar, but incompatible, with the 9-bit syscmd used by 4640 style processors. all other bus signals and timings are compatible between the two processor bus protocols. the encodings for syscmd[4:0] are shown in the tables below. note that many encodings are not defined; these encodings are reserved and must not be used. in 4300 mode, syscmd[8:5] are not used and should be tied to gnd. a summary of bit usage is shown below. table 5. syscmd bit summary syscmd bit function syscmd[4] 0 = transaction information (read/write/size) 1 = data information (good/bad/last) syscmd[3] read/write indicator for address cycles 0 = read transaction 1 = write transaction last data indicator for data cycles 0 = last data 1 = not last data syscmd[2] read/write attributesfor address cycles 0 = single read/write 1 = block read/write response data indicator for data cycles 0 = response data 1 = not response data reserved for cpu driven data cycles syscmd[1:0] size indicator for reads/writes for address cycles error status indicator for data cycles.
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 20 revision 1.0 1. x denotes dont care but x signals are driven to a valid 0/1. table 6. address phase syscmd[4:0] encodings (driven by cpu/local master) syscmd[4:0] encoding command mnemonic command description 4 3 2 1 0 00000 rdbyte read a single byte 00001 rdshort read 16 bits 00010 rdtribyte read 3 bytes 00011 rdword read 4 bytes (single word) 00100 rd2words read 2 words (8 bytes) in a burst 00101 rd4words read 4 words (16 bytes) in a burst 00110 rd8words read 8 words (32 bytes) in a burst 01000 wrbyte write a single byte 01001 wrshort write 16 bits 01010 wrtribyte write 3 bytes 01011 wrword write 4 bytes (single word) 01100 wr2words write 2 words (8 bytes) in a burst 01101 wr4words write 4 words (16 bytes) in a burst 01110 wr8words write 8 words (32 bytes) in a burst table 7. data identifier syscmd[4:0] encodings (driven by GT-64111) syscmd[4:0] encoding 1 command mnemonic command description 4 3 2 1 0 1 0 0 e x reod indicates last valid data in a burst e = 0 data is good e = 1 data is erroneous 1 1 0 e x rd indicates valid data within a burst e = 0 data is good e = 1 data is erroneous
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 3.4 operation of wrrdy* and the internal write posting queues the GT-64111s cpu/local master interface includes a write posting queue that absorbs local cpu/local master writes at zero wait-states. this is required per the mips sysad bus write protocol. the write posting queue has 4 address entries and 16 32-bit data entries. the GT-64111 signals if there is room in the cpu/local master write posting queue by asserting wrrdy*. if wrrdy* is asserted then the cpu/local master may issue a write of up to 8 words. wrrdy* will be deasserted the cycle immediately following when: ? the address fifo has two valid entries and a third address is being pushed, or... ? the address fifo has more than two valid entries, or... ? the address fifo has two valid entries or more, the data fifo has four valid entries and a fifth one is being pushed, or... ? the address fifo has two valid entries or more, the data fifo has more than four valid entries, or... ? the address fifo has one valid entry, the data fifo has six valid entries and a seventh one is being pushed, or... ? the address fifo has one valid entry, the data fifo has more than six valid entries. wrrdy* will be re-asserted the cycle following a transaction away from the states above. it is not necessary to take the above scenarios into account when designing a system with the GT-64111. mips compli- ant processors such as the r4640 and r4650 sample wrrdy* automatically before issuing a write. only dma devices on sysad need to be concerned about the functionality of wrrdy*, as mentioned above. 3.5 mips write modes and write patterns supported the GT-64111 supports both pipelined and r4000 compatible write modes (with 2 dead cycles between consecutive writes). the default mode is pipelined, however r4000 mode can be selected in the cpu/local master interface con- figuration register. the cpu/local master interface supports only dddddddd and dxdxdxdxdxdxdxdx write patterns. be sure to select one of these two write patterns via the mips serial initialization bitstream during the cpu/local master reset pro- cess. 3.6 cpu/local master interface endianess the GT-64111 provides the capability to swap the endianess of data transferred to/from the internal registers, to/from the pci interface, and to/from the memory bus. please see the relevant chapter in the applications section for more information. 1. x denotes dont care but x signals are driven to a valid 0/1. table 8. cpu/local master data identifier syscmd[4:0] encodings (driven by cpu/local master syscmd[4:0] encoding 1 command mnemonic command description 4 3 2 1 0 1 0 1 e x weod indicates last valid data in a burst e = 0 data is good e = 1 data is erroneous 1 1 1 e x wd indicates valid data within a burst e = 0 data is good e = 1 data is erroneous
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 22 revision 1.0 3.7 burst order the GT-64111 supports the sub-block ordered bursts used by orion mips processors, by default. sub-block ordered bursts are optimized for the burst patterns used by most synchronous srams and sdrams. linear burst order is also supported for attaching processors other than the mips family. linear burst order is enabled by setting bit 9 in the dram bank2 parameters register at offset 0x454. 3.8 cpu/local master interface restrictions 1. the cpu should not attempt an access before 10 tclk cycles following deassertion of rst* have expired. 2. cacheopmap should not be written to a value other than 0 unless cachepres bit is set (see register section). 3. the cpu interface supports only dddddddd and dxdxdxdxdxdxdxdx write patterns. 4. a pci i/o read intended for synchronization barrier should not be more than one long word (4 bytes). any pci i/o read of more than 4 bytes will be carried out without checking the internal fifos. 5. a write of more than 4 bytes to internal space will be ignored. a read of more than 4 bytes to internal space will result in transaction termination with bus-error indication (syscmd[5] equal 1). 6. validout* signal must have a pullup resistor to vcc. this is done in order to prevent GT-64111 to identify wrongly the cpu type (rc4640/rm523x or r4300) due to unstable validout* signal when getting out of reset.
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 4. address space decoding the GT-64111 has a fully programmable address map. two address spaces exist: the cpu/local master address space and the pci address space (see figure 5.) both address maps use a two-stage decoding process where major device regions are decoded first, then the individual devices are subdecoded. figure 5: two stage address decoding- conceptual view dram bank ras0 -or- ras1 dram bank ras3 -or- ras2 galileo internal registers devices (multiple decoders) device decoders ras0 bank ras1 bank ras2 bank ras3 bank bootcs* cs0* cs1* cs2* cs3* dram bank ras0 -or- ras1 dram bank ras3 -or- ras2 galileo internal registers pci memory0 window pci i/o window devices (multiple decoders) pci memory1 window internal galileo registers to pci bus device bus (ad bus) device control signals pci base address registers processor decode registers
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 24 revision 1.0 4.1 two stage decoding process the system resources are divided into eight groups: ras[1:0], ras[3:2], cs[2:0], cs[3] & bootcs, internal registers, pci i/o, and pci memory0/1. each group can have a minimum of 2 mbytes and a maximum of 256 mbytes of address space. the individual devices in the device groups (e.g. ras[0]) are further sub decoded to 1 mbyte resolution. table 9 shows the cpu/local master decode and device sub-decode associations, table 10 shows the same process for pci. 1. this mapping also applies to the swap bars located in pci function 1, if enabled. 2. this feature is available only in the gt-64011-p-1 stepping table 9. cpu/local master and device decoder mappings cpu/local master decoder associated device sub-decoders ras[1:0] ras0* ras1* ras[3:2] ras2* ras3* cs[2:0] cs0* cs1* cs2* bootcs*/cs3* bootcs* cs3* pci i/o none, accesses decoded for pci i/o are bridged to pci i/o transfers. pci memory 0/1 none, accesses decoded for pci memory 0/1 are bridged to pci memory transfers. internal none, decodes to GT-64111 internal registers. table 10. pci base address register and device decoder mappings pci base address register (bar) decoder 1 associated device sub-decoders ras[1:0] - bar 0 at 0x10 ras0* ras1* ras[3:2] - bar 1 at 0x14 ras2* ras3* cs[2:0] - bar 2 at 0x18 cs0* cs1* cs2* bootcs*/cs3* - bar 3 at 0x1c bootcs* cs3* internal registers (memory) - bar 4 at 0x20 none, decodes pci memory accesses to gt- 64111 internal registers. internal registers (i/o) - bar 5 at 0x24 none, decodes pci i/o accesses to GT-64111 internal registers. expansion rom - bar at 0x30 none, decodes directly to cs3* 2
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 4.1.1 cpu/local master side decoding process decoding on the cpu/local master side starts with the sysad address being compared with the values in the various cpu/local master low and high decoder registers. for example, the ras[1:0] cpu/local master high and low decoder registers set the address range in which the ras0* and ras1* signals are active (i.e. where dram banks 0 and 1 are located.) the comparison works as follows: ? bits 31:28 of the sysad address are compared against bits 10:7 in the various cpu/local master low decode registers. these values much match exactly. this effectively sets a 256 mbyte page for the resource group. ? bits 27:21 of the sysad address are then compared against bits 6:0 in the various cpu/local master low decode registers. the value of the sysad bits must be greater than or equal to the low decode value. this sets the lower boundary for the region. ? bits 27:21 of the sysad address are then compared against the high decode registers. the value of the sysad bits must be less than or equal to this value. this sets the upper bound for the region. ? if all of the above are true, then the resource group is selected and a subdecode is perfomed to determine the specific resource. once a cpu/local master resource group has been decoded, it must be subdecoded to determine which physical device should be accessed within that group. this decoding is controlled by the device low and high decode registers. the comparison works as follows: ? bits 27:20 of the sysad address are then compared against the relevant device low decode registers. the value of the sysad bits must be greater than or equal to the low decode value. this sets the lower boundary for the sub-decode region. ? bits 27:20 of the sysad address are then compared against the relevant device high decode registers. the value of the sysad bits must be less than or equal to this value. this sets the upper bound for the sub-decode region. ? if all of the above are true, then the specific device is selected and an access to that device is performed. examples of the cpu/local master-side decode process are shown in figure 6 and figure 7.
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 26 revision 1.0 figure 6: cpu/local master-side resource group decode function and example = = = = >= >= >= >= >= >= >= 31 30 29 28 27 26 25 24 23 22 21 20 <= <= <= <= <= <= <= low processor decode reg high processor decode reg sysad address bits 0 1 0 0 0 0 0 0 0 0 0 31 30 29 28 27 26 25 24 23 22 21 20 0 0 1 1 1 1 1 low processor decode reg high processor decode reg sysad address bits example: set up a sysad decode region that starts at 0x4000.0000 and is 64mbytes in length (0x4000.0000 to 0x43ff.ffff): if the sysad address is between the low and the high decode addresses, then the access is passed to the device unit for sub- decode.
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 figure 7: device sub-decode function and example = = = = >= >= >= >= >= >= >= 31 30 29 28 27 26 25 24 23 22 21 20 <= <= <= <= <= <= <= low processor decode reg high processor decode reg sysad address bits <= <= <= <= <= <= <= <= >= >= >= >= >= >= >= >= a match ("hit") in the processor decoders forwards the address to the device sub-decoders low device decode reg high device decode reg 0 1 0 0 0 0 0 0 0 0 0 31 30 29 28 27 26 25 24 23 22 21 20 0 0 1 1 1 1 1 low processor decode reg high processor decode reg sysad address bits 0 0 0 0 0 1 1 1 0 0 0 0 0 0 0 0 a match in the processor decoders forwards the address to the device sub- decoders low device decode reg high device decode reg processor resource group decode region (64mbyte) 0x43ff.ffff device sub-decode region (8 meg) 0x4000.0000 0x407f.ffff example: usin g the previous cpu/local master decode example (0x4000.0000 to 0x43ff.ffff), place a device sub-decode in the first 8 me g : 0x4000.0000 to 0x407f.ffff
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 28 revision 1.0 4.2 pci side decoding process decoding on the pci side starts with the pci address being compared with the values in the various base address registers. for example, the ras[1:0] base address register sets the pci base address range in which the ras0* and ras1* signals are active (i.e. where dram banks 0 and 1 are located in pci space.) the size of the window in pci space for each base address register is set by the bank size registers for each base address register. the bank size sets which address bits are significant for the comparison between the active pci address and the values in the base address registers (see figure 8). figure 8: bank size register function example (16meg decode) the comparison works as follows: ? bits 31:n of the pci address are compared against bits 31:n in the various base address registers (bar). these values much match exactly. the value of n is set by the least significant bit with a 0 in the bank size registers (for example, n would be equal to 24 in the example shown in figure 8, above.) ? if all of the above is true, then the resource group is selected and a subdecode is perfomed to determine the specific resource. once a resource group has been decoded by a bar, it must be subdecoded to determine which physical device should be accessed within that group. this decoding is controlled by the device low and high decode registers. note that these registers are the same ones used for cpu/local master-side decoding. this means that the pci and sysad memory maps are coupled at the device decoders. address bits 27:20 (the bits compared by the device decoders) for any given device overlap in both the pci and sysad maps. the sub-decoding comparison works as follows: ? bits 27:20 of the pci address are then compared against bits the relevant device low decode registers. the value of the pci address bits must be greater than or equal to the low decode value. this sets the lower boundary for the sub-decode region. ? bits 27:20 of the pci address are then compared against the relevantbdevice high decode registers. the value of the pci address bits must be less than or equal to this value. this sets the upper bound for the sub- decode region. ? if all of the above are true, then the specific device is selected and an access to that device is performed. note that the coupling of the sysad, pci, and device memory maps requires special attention for designers of pc plug and play adapters. please see galileos apnote for this application on our website. 4.3 disabling the device decoders any device sub-decoder can be disabled by setting the value of the low decoder to be higher than the high decoder. 4.4 dma unit address decoding the dma controller uses the address mapping of the cpu/local master interface when accessing the device/dram bus. the dma unit can access the pci bus independent of the cpu/local master-side pci bridge decoders on the gt-64011 and gt-64060 devices only (see dma section.) 0 0 0 0 0 0 0 0 1 1 1 31 30 29 28 27 26 25 24 23 22 21 20 1 bank size reg pci address bits 1 1 1 1 1 1 1 19 18 17 16 15 14 13 12 1 = = = = = = = = x x x x x x x x x x x x '=' means must match exactl y 'x' means don't care comparison against pci address
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 4.5 address space decoding errors when the cpu/local master tries to access an address from the sysad that is not supported, the GT-64111 will latch the address into the bus error register, and will issue a bus error (over syscmd[5]) if the access was a read access, and an interrupt if it was a read or write access. this feature is especially useful during software debug, when errant code can cause fetches from unsupported addresses. when a pci access hits in a base address register then misses in the associated subdecoders, the result will be ran- dom data returned on a read; write data is discarded. the memout bit in the interrupt cause register is also set. accesses that miss all of the GT-64111 bars result in no response at all from the GT-64111, as you would expect. note: address space decoders must never be programmed to overlap; unpredictable behavior will result. 4.6 default memory map the default cpu/local master memory map that is valid following reset is shown in table 11 below. the default pci map and bar sizing information is shown in table 12 and table 13. table 11. cpu/local master and device decoder default address mapping cpu/local master decode range and size resource group device decode range and size device selected 0x0 to 0x00ff.ffff 16 megabytes ras[1:0] 0x0 to 0x007f.ffff 8 megabytes ras0* 0x0080.0000 to 0x00ff.ffff 8 megabytes ras1* 0x0100.0000 to 0x01ff.ffff 16 megabytes ras[3:2] 0x0100.0000 to 0x017f.ffff 8 megabytes ras2* 0x0180.0000 to 0x01ff.ffff 8 megabytes ras3* 0x1000.0000 to 0x11ff.ffff 32 megabytes pci i/0 no subdecode, access bridged directly to pci i/o space pci 0x1200.0000 to 0x13ff.ffff 32 megabytes pci mem0 no subdecode, access bridged directly to pci memory space pci 0x1c00.0000 to 0x1e1f.ffff ~32 megabytes cs[2:0] 0x1c00.0000 to 0x1c7f.ffff 8 megabytes cs0* 0x1c80.0000 to 0x1cff.ffff 8 megabytes cs1* 0x1d00.0000 to 0x1dff.ffff 16 megabytes cs2* 0x1f00.0000 to 0x1fff.ffff 16 megabytes cs[3] and bootcs* 0x1f00.0000 to 0x1fbf.ffff 12 megabyte cs3* 0x1fc0.0000 to 0x1fff.ffff 4 megabytes bootcs* 0xf200.0000 to 0xf3ff.ffff 32 megabytes pci mem1 no subdecode, access bridged directly to pci memory space pci
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 30 revision 1.0 table 12. pci function 0 and device decoder default address mapping pci function 0 decode range and size resource group device decode range and size device selected 0x0 to 0x00ff.ffff 16 megabytes in memory space ras[1:0] 0x0 to 0x007f.ffff 8 megabytes ras0* 0x0080.0000 to 0x00ff.ffff 8 megabytes ras1* 0x0100.0000 to 0x01ff.ffff 16 megabytes in memory space ras[3:2] 0x0100.0000 to 0x017f.ffff 8 megabytes ras2* 0x0180.0000 to 0x01ff.ffff 8 megabytes ras3* 0x1400.0000 to 0x1400.0fff 4 kbytes in memory space internal registers no subdecode internal registers 0x1400.0000 to 0x1400.0fff 4 kbytes in i/o space internal registers no subdecode internal registers 0x1c00.0000 to 0x1dff.ffff 32 megabytes in memory space cs[2:0] 0x1c00.0000 to 0x1c7f.ffff 8 megabytes cs0* 0x1c80.0000 to 0x1cff.ffff 8 megabytes cs1* 0x1d00.0000 to 0x1dff.ffff 16 megabytes cs2* 0x1f00.0000 to 0x1fff.ffff 16 megabytes in memory space cs[3] and bootcs* 0x1f00.0000 to 0x1fbf.ffff 12 megabyte cs3* 0x1fc0.0000 to 0x1fff.ffff 4 megabytes bootcs* 0x1f00.000 to 0x1fff.ffff 16 megabytes (uses cs[3] and bootcs* size register) pci expansion rom no subdecode. this decoder is used only during pc bios initial- ization. cs3* table 13. pci function 1 (byte order swap) and device decoder default address mapping pci function 0 decode range and size resource group device decode range and size device selected 0x0 to 0x00ff.ffff 16 megabytes in memory space ras[1:0] 0x0 to 0x007f.ffff 8 megabytes ras0* 0x0080.0000 to 0x00ff.ffff 8 megabytes ras1* 0x0100.0000 to 0x01ff.ffff 16 megabytes in memory space ras[3:2] 0x0100.0000 to 0x017f.ffff 8 megabytes ras2* 0x0180.0000 to 0x01ff.ffff 8 megabytes ras3* 0x1f00.0000 to 0x1fff.ffff 16 megabytes in memory space cs[3] and bootcs* 0x1f00.0000 to 0x1fbf.ffff 12 megabyte cs3* 0x1fc0.0000 to 0x1fff.ffff 4 megabytes bootcs*
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 5. memory controller the GT-64111s memory controller consists of a dram controller and a device controller. the dram controller has an independent 12-bit address bus (dadr[11:0]) and shares the 32-bit address/data (ad) bus for data transfers. the device controller uses the 32-bit ad bus for both address and data transfers. all memory and i/o devices in a gt- 64111 system are connected to the ad bus (the sysad bus is used primarily as a point-to-point connection between cpu and chipset.) the memory controller will only master read and write transactions to dram or devices, as instructed from the cpu, dma controller, or a pci master on the pci bus. a device on the ad bus may not master transactions to other devices, dram or the pci via the GT-64111s memory controller. the GT-64111s memory con- troller can support 32 or 64-bit (32-bit interleaved) dram as well as 8-, 16-, 32-, and 64-bit (32-bit interleaved) devices. the GT-64111 implements a round robin arbitration scheme for requests of the memory controller as shown in figure 9. figure 9: memory controller arbitration 5.1 dram controller the dram controller supports up to four banks of page mode or edo dram. the dram configuration register (0x448) contains configuration information which is valid for all banks. various access parameters can be programmed on a per bank basis as each bank has its own parameters register (0x44c - 0x458). the supported address depth of the dram can vary for each bank separately from 256k (9-bit ras*, 9-bit cas*) to 16m (12-bit ras*, 12-bit cas*), and the width of each bank may be 32 bits or 64 bits (32-bit interleaved). with these options, each dram bank can vary in size from 1 mbyte to 128 mbytes. the maximum total dram address space is 512mbytes for four banks. 5.1.1 dram refresh 5.1.1.1 refresh rates the GT-64111 implements standard cas* before ras* refreshing. refresh rates for all banks can be programmed to occur at different frequencies according to the refintcnt, a 14-bit value dram configuration register. for example, the default value of refintcnt is 0x200. if tclk is 50 mhz, than a refresh sequence will occur every 10us. this is derived from 50mhz (=20ns) * 0x200 (512d) = 10.24us. every instance that the refresh counter in the GT-64111 reaches its ter- minal count, a refresh request is sent to the memory controller. this dram refresh request enters the arbiter, and the refresh cycle will begin once the memory controller has been arbitrated for this request. 5.1.1.2 non-staggered and staggered refresh non-staggered or staggered refresh for all banks can be programmed according to stagref in the dram configuration register. in non-staggered refresh, ras[3:0] will simultanously assert following the low-going cas* refreshing all banks at the same time as shown in figure 10. if the dram controller is programmed to performed staggered refresh cpu pci dma controller dram refresh
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 32 revision 1.0 (default), ras[3:0] will not simulataneously assert low following the low-going cas*. rather, ras[0] will first go low, followed by ras[1] on the next tclk, and so on. after the last ras, ras[3] has asserted low, cas* will go high again followed by ras[0] on the next tclk, ras[1] on the following tclk, and so on. staggered refresh is useful for load balancing, shown in figure 11. figure 10: non-staggered refresh waveform figure 11: staggered refresh waveform 5.1.2 assymetrically ras*/cas* addressing the GT-64111 supports assymetrical ras*/cas* addressing. in other words, a different number of addressing bits may be valid for row addressing as compared to column addressing. 9, 10, 11 or 12 bits can be used for dram row addressing and is specified on a per bank basis by programming bits 5:4 of the dram bank[3:0] parameter registers (0x44c-0x458). these bits determine the decoding of an address asserted on the sysad bus from a device such as a cpu or from a pci system on the pci bus. some bits of the address are used for ras* while others are used for cas*. the active sysad or pad pins which are translated to the dadr pins are shown in table 14 for 32-bit dram and in table 15 for 64-bit dram (32-bit interleaved). table 14. active dadr[11:0] bits for ras* and cas*, 32-bit dram table 15. active dadr[11:0] bits for ras* and cas*, 64-bit dram (32-bit interleaved) 1. regardless of 5:4, dadr[11:0] will always have the value of sysad/pad[16:5] during ras*. 1. regardless of 5:4, dadr[11:0] will always have the value of sysad/pad[16:5] during ras*. dram bank para. 5:4 row addr. depth active ras* dadr bits 1 sysad/pad bits used for ras* on dadr sysad/pad bits used for cas* on dadr[11:0] 00 512 8:0 13:5 22..20, 16..14, 19..17, 4..2 01 1k 9:0 14:5 23..21, 16..15, 20..17, 4..2 10 2k 10:0 15:5 24..22, 16, 21..17, 4..2 11 4k 11:0 16:5 25..17, 4..2 dram bank para. 5:4 row addr. depth active ras* dadr bits 1 sysad/pad bits used for ras* on dadr sysad/pad bits used for cas* on dadr[11:0] 00 512 8:0 13:5 23..20, 16..14, 19..17, 4..3 01 1k 9:0 14:5 24..21, 16..15, 20..17, 4..3 10 2k 10:0 15:5 25..22, 16, 21..17, 4..3 11 4k 11:0 16:5 26..17, 4..3 tclk ras[3:0] ecas[3:0] ocas[3:0] 0 f f f 0 f tclk ras [ 3:0 ] ecas [ 3:0 ] ocas [ 3:0 ] 8 c e f 7 3 1 0f f f 0
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 for example, when using 32-bit dram, if bits 5:4 are 01, for a particular bank, an address decoded to that bank from the sysad/pad bus will cause the dadr bus to act as follows: during ras* phase, dadr[9:0] will have the values of sysad/pad[13:5]. during cas* phase, dadr[11:0] will have the values of {sysad/pad[23:21], sysad/pad[16:15], sysad/pad[20:17], sysad/pad[4:2]}. 5.1.3 dadr[11]/ads* function the default state of dadr[11]/ads* is to function only as dadr[11]. optionally, this pin is software configurable to only behave as ads* via bit 17 of the dram configuration register. when this pin functions as ads*, it is an active low address strobe which indicates the beginning of a device transaction. this pin is sampled as an input at reset for con- figuration purposes. 5.1.4 programmable dram timing parameters the dram controller of the GT-64111 supports a wide range of drams with different access times and each bank can be programmed independently by the dram bank[3:0] parameter registers (0x44c-0x458). these paramaters include the number of clock cycles (based on tclk) that cas* is asserted (low) in a write access (caswr, bit 0) and in a read access (casrd, bit 2). the number of clocks cycles (based on tclk) between active ras* and cas* in a write access (rastocaswr, bit 1) and in read access (rastocasrd, bit 3) can also be programmed. 5.1.4.1 asserted cas* the number of clocks that cas* is asserted in low in write and read accesses can be programmed to be either one (figure 12) or two clocks (figure 13). 2 clocks is the default number that cas* is low for both write and read accesses. both the high and low-going edges of cas* are driven from a rising tclk. figure 12: cas* asserted for 1 clock figure 13: cas* asserted for 2 clocks selecting the caswr and casrd parameter will depend on ? dram cas* pulse width minimum requirement time ? tclk frequency for example, standard 60ns edo dram has a 10ns minimum pulse requirement for cas*. if tclk is set to 50 mhz (20ns), both caswr and casrd can be programmed to one cycle for maximum performance. this will result in read- ing/writing one datum every two clocks (for 32-bit dram). on the other hand, slower page mode drams will have cas* low for 1 tclk cas* asserted from rising tclk tclk . . . cas* de-asserted from rising tclk cas* cas* low for 2 tclks cas* asserted from rising tclk tclk cas* de-asserted from rising tclk cas* . . .
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 34 revision 1.0 longer access times requiring the GT-64111 to assert cas* for two clocks instead of one. 5.1.4.2 ras* to cas* the number of clocks between active ras* and cas* in write and read accesses can be programmed to be either two (figure 14) or three clocks (figure 15). 3 clocks is the default delay between active ras* and active cas*. figure 14: two clock delay between active ras* to active cas* figure 15: three clock delay between active ras* to active cas* selecting the rastocaswr and rastocasrd parameter will depend on ? dram ras* to cas* maximum delay time ? tclk frequency 5.1.5 dram bank width and location bit 6 of the dram bank[3:0] parameter registers (0x44c-0x458), bankwidth, specifies whether the data width of the particular bank of dram is 32-bit (default) or 64-bit (32-bit interleaved). if the bank is set for 32-bit operation, it can either reside on the even (default) or odd bank by setting bit 7, bankloc. selecting the even or the odd bank allows for load balancing. if the bankwidth is programmed to 1 indicating the bank is set for 64-bit (32-bit interleaved), the setting of bankloc is irrelavent as both banks will be populated. 5.1.6 dram performance dram performance is based on the width of dram implemented (32 or 64-bit) as well as the setting of the dram parameters. table 16 lists the performance when the cpu reads a cache line (8 32-bit words) from dram. the perfor- mance is measured from validout* asserted by the processor with the rd8words command to the GT-64111 asserting validin* responding with the first datum. for example, 8-1-1-1-1-1-1-1 performances indicates 8 tclks from validout* asserted to validin* asserted for the first datum and 1 tclk for every following datum (0 wait states). 10-3-3-3-3-3-3-3 indicates 10 tclks from validout* asserted to validin* asserted for the first datum and 3 tclks for every following tclk ras* . . . cas* . . . ras* to cas*, 2 tclks tclk ras* . . . cas* . . . ras* to cas*, 3 tclks
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 datum (2 wait states). table 16. dram performance 5.2 device controller the device controller supports up to five banks of devices. various access parameters can be programmed on a per bank basis as each bank has its own parameters register (0x45c - 0x46c). the supported memory space of each device bank can vary for each bank separately up to 32 mbytes, and the width of each bank may be 8, 16, 32 or 64 bits the maximum total device address space is 160mbytes for five banks. the 5 individual chip selects are typically bro- ken up into 4 individual device banks plus one chip select for a boot device (non-volatile memory). bootcs* has the exact same functionality as cs[3:0] and devices which need to be read from and written to can be attached to this chip select. the only difference between bootcs* and cs[3:0] is that by default, bootcs* is mapped to the physical boot address of 0x1fc0.0000 (which can be reprogrammed) and its device width can be programmed by input pins on reset. each device bank can have unique programmable timing parameters to accommodate different device types (e.g. flash, sram, rom, i/o controllers). the devices share the local ad bus with the dram, but unlike dram, the devices use the ad bus as a multiplexed address and data bus. in the address phase, the device controller puts on the ad bus an address with a corresponding chip select asserted. ale (and ads* if programmed, section 5.1.3) indicates the ad bus is outputing an address and cs*, devrw* and dmaack*. ale is used to latch the address, cs*, devrw* and dmaack* in an external 373. cs* should then be qual- ified (or-tied) with cstiming*. a read or write cycle is indicated by the latched devrw*. the cstiming* signal will be valid for the programmable number of cycles of the specific cs* that is active. turnoff, acctofirst and acctonext can be set in registers 0x45c - 0x46c for each banks read timing parameters (see figure 16 for waveform example without latches enabled, see figure 17 for waveform example with latches enabled). adstowr, wractive and wrhigh can be set for each banks write timing parameters (see figure 18 for waveform example). please see section 5.6 before con- figuring these bits. acctofirst, acctonext and wractive can be extended by the ready* pin (see section 5.2.10). 5.2.1 turnoff, bits [2:0] turnoff is the number of tclk cycles that the GT-64111 will not drive the memory bus after a read from a device. this prevents contentions on the memory bus after a read cycle for a slow device. this parameter is measured from the the number of cycles between the deassertion of devoe* (an externally extracted signal which is the logical or between cstiming* and inverted devrw*) to an new ad bus cycle. 5.2.2 acctofirst, bits [6:3] acctofirst defines the number of cycles in a read access from the assertion of cs* to the cycle that the data will be latched (by external latches). this parameter can also be thought as the delay between the rising edge of tclk which drives ale high to the the rising edge of tclk where the first data will be latched by the external latches. if there are no latches in the system, acctofirst defines the number of cycles between tclk which drives ale high to the rising edge of tclk where the first data is latched into the GT-64111. this parameter can be extended by the ready* pin. 5.2.3 acctonext, bits [10:7] acctonext defined as the number of cycles in a read access from the cycle that the first data was latched to the cycle 1. 8-2-2-2-2-2-2-2 with 32-bit drams and 8-1-1-1-1-1-1-1 clocks with 64-bit (32-bit interleaved) drams is the performance for r as- tocasrd = 0 and casrd = 0. in wait-state nomenclature this equates to 5-1-1-1-1-1-1-1 and 5-0-0-0-0-0-0-0.) dram width rastocasrd = 0 casrd = 0 1 rast oc asr d = 0 casrd = 1 rastocasrd = 1 casrd = 0 rast oc asr d = 1 casrd = 1 32-bit 8-2-2-2-2-2-2-2 9-3-3-3-3-3-3-3 9-2-2-2-2-2-2-2 10-3-3-3-3-3-3-3 64-bit (32-bit interleaved) 8-1-1-1-1-1-1-1 9-1-2-1-2-1-2-1 9-1-1-1-1-1-1-1 10-1-2-1-2-1-2-1
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 36 revision 1.0 to the next data will be latched (in burst accesses). this parameter can also be thought of as the delay between the ris- ing edge of tclk which data is latched to the rising edge of tclk where the next data is latched in a burst cycle. this parameter can be extended by the ready* pin. 5.2.4 adstowr, bits[13:11] there are eight byte write signals, four for even bank devices (ewr[3:0]*) and four for odd bank devices (owr[3:0]*). adstowr can also be thought as the delay between the rising edge of tclk which drives ads* low (ale high) from to the assertion of ewr* or owr*, or for the first write pulse. 5.2.5 wractive, bits[16:14] wractive is the number of tclks that ewr* and owr* are active (asserted). this parameter is measured from the first rising edge of tclk where ewr* or owr* is asserted low to the last rising edge of tclk where ewr* or owr* is low for that particular write pulse. this parameter can be extended by the ready* pin. 5.2.6 wrhigh, bits[19:17] wrhigh is the number of tclks that ewr* and owr* are inactive between burst writes. this parameter is measured from the first rising edge of tclk where ewr* or owr* is de-asserted high to the last rising edge of tclk where ewr* or owr* is high. on the next rising edge of tclk, ewr* and owr* will be asserted low for the next write pulse. these signals are driven off of the falling edge of tclk.
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 figure 16: waveform showing device read parameters, latchfunct = 0 address tclk ale ads* 1 ad[31:0] acctofirst = 6 acctonext = 3 turnoff = 3 data 1 cs* 2 cstiming* devrw* notes: 1. assumes dadr11/ads* is programmed to be ads* only 2. cs* is driven off the same rising tclk* as ale (and ads*). throughout consecutive transactions to the same device, cs* will remain asserted. this is why cs* must always be qualified with cstiming*. 3. ad[31:0] (data 1) sampled by gt-64011. 4. ad[31:0] (data 2) sampled by gt-64011. 5. gt-64011 may drive ad[31:0] after turnoff. 6. oeb is programmed active low. data 2 3 4 5 oeb lee/ leo oee*/ oeo* dev[31:0] data 1 driven from device data 2 driven from device
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 38 revision 1.0 figure 17: waveform showing device read parameters, latchfunct = 1 address tclk ale ads* 1 ad[31:0] acctofirst = 5 acctonext = 3 turnoff = 4 data 1 cs* 2 cstiming* devrw* notes: 1. assumes dadr11/ads* is programmed to be ads* only 2. cs* is driven off the same rising tclk* as ale (and ads*). throughout consecutive transactions to the same device, cs* will remain asserted. this is why cs* must always be qualified with cstiming*. 3. ad[31:0] (data 1) sampled by gt-64011. 4. ad[31:0] (data 2) sampled by gt-64011. 5. gt-64011 may drive ad[31:0] after turnoff. 6. oeb is programmed active low. data 2 lee/ leo 3 4 5 dev[31:0] data 1 driven from device data 2 driven from device oee*/ oeo* oeb
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 figure 18: waveform showing device write parameters 5.2.7 burst transactions the device controller supports a maximum of 8 32-bit word burst accesses. the burst address is supported by a three bit wide address bus (badr[2:0]) that is different from the latched address on the multiplexed ad bus. note that badr[2:0] are the same pins as the least significant dram address lines, dadr[2:0]. see pin assignment table for more detail. 5.2.8 packing and unpacking data and burst support the GT-64111 supports the packing of data into a 32-bit word, in reads from devices that are 8 or 16-bits wide. devices that are 8-bits or 16-bits wide only are supported by partial reads (up to 64-bits). the controller supports cpu writes of 1 to 8 bytes to 8-bit or 16-bit wide devices. therefore, 8 and 16-bit devices must not be mapped to cacheable regions. the reason is that the r4640 has an 8-word (32 bytes) cache line size. this would equate to a burst of 32 8- bit accesses or 16 16-bit accesses. the GT-64111 supports cached accesses to 32 and 64-bit device spaces. it supports dma/pci writes of 1 to 4 bytes to 8-bit or 16-bit wide devices. 5.2.9 destructive reads when the cpu performs an device read from an 8-bit device, there are certain conditions where the device controller will fetch additional data even though it is never read by the cpu. designers using devices such as fifos must be aware of these destructive reads. destructive reads will not occur on read accesses from 16, 32 or 64-bit devices. when a pci master reads data from 8 or 16-bit devices, or when data is read from 8 or 16-bit devices via the dma con- address tclk ale ads* 1 ad[31:0] adstowr = 3 wractive = 3 wrhigh= 3 wractive = 3 ewr owr 3 gt-64011 drives valid data 1 gt-64011 drives valid data 2 cs* 2 cstiming* devrw* notes: 1. assumes dadr11/ads* is programmed to be ads* only. 2. cs* is driven off the same rising tclk* as ale (and ads*). throughout consecutive transactions to the same device, cs* will remain asserted. this is why cs* must always be qualified with cstiming*. 3. ewr[3:0]* and owr[3:0]* are asserted and deasserted from the falling edge of tclk. 4. oeb is programmed active low. lee/leo oeb
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 40 revision 1.0 trollers, only single word reads are allowed. 5.2.9.1 8-bit devices if a device bank is set to support 8-bit devices, and the cpu executes a 2 or 3 byte read, the device controller will fetch extra data. if the cpu executes a 1 or 4 byte read, the device controller will not fetch extra data. see table 17 for a summary. table 17. destructive reads, 8-bit device 5.2.10 ready* support the ready* pin is sampled on three occasions: one clock before the data is sampled to the GT-64111 during both acctofirst (see figure 19) and acctonext (see figure 20) phases of read cycles and on the last rising edge of the wractive (see below) phase during a write cycle. during all other phases ready* is not sampled by the GT-64111. if ready* is not asserted during these clocks, the wractive, acctofirst or acctonext phases are extended until ready* is asserted again. the transaction may be indefinitely held off until ready* is asserted. # byte read from cpu destructive read? # of additional bytes read 1no0 2yes2 3yes1 4no0
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 figure 19: ready* extending acctofirst on read cycle, latches disabled tclk ale ads* 1 acctofirst programmed to 6 cs* 2 cstiming* devrw* notes: 1. assumes dadr11/ads* is programmed to be ads* only 2. cs* is driven off the same rising tclk* as ale (and ads*). throughout consecutive transactions to the same device, cs* will remain asserted. this is why cs* must always be qualified with cstiming*. 3. ready* is sampled as deasserted one clock before data should be sampled according to acctofirst. ad[31:0] is not sampled by the gt-64011 on the following rising tclk. 4. ready* is asserted on some following rising tclk. 5. ad[31:0] (data 1) is sampled on the following rising tclk of the rising tclk that ready* was asserted. effectively, acctofirst is 8 in this example (instead of the programmed 6). 5 ready* 3 4 address ad[31:0] data 1 driven from device
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 42 revision 1.0 figure 20: ready* extending acctonext on read cycle, latches disabled address tclk ale ads* 1 ad[31:0] acctofirst = 6 acctonext programmed to 3 data 1 driven from device cs* 2 cstiming* devrw* notes: 1. assumes dadr11/ads* is programmed to be ads* only 2. cs* is driven off the same rising tclk* as ale (and ads*). throughout consecutive transactions to the same device, cs* will remain asserted. this is why cs* must always be qualified with cstiming*. 3. ready* is sampled as asserted one clock before data should be sampled according to acctofirst. data 1 is sampled on ad[31:0]. 4. ready* is sampled as deasserted one clock before data should be sampled according to acctonext. data 2 is not sampled. 5. ready* is asserted on some following rising tclk. 6. ad[31:0] (data 2) is sampled on the following rising tclk of the rising tclk that ready* was asserted. effectively, acctonext is 5 (instead of the programmed 3). data 2 driven from device 5 ready* 3 4 6
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 figure 21: extending wractive parameter on write cycle 5.2.11 device bank width and location bit 21:20 of the device bank[3:0] parameter registers (0x45c-0x46c), devwidth, specifies whether the data width of the particular device bank is 8, 16, 32 (default except for bootcs*), or 64-bit (32-bit interleaved). if the bank is set for 8, 16 or 32-bit, it can be placed on the even or odd bank depending on the setting of devloc. if the devwidth is pro- grammed to 11 indicating the bank is set for 64-bit (32-bit interleaved), the setting of devloc is irrelavent as both banks will be populated. selecting the even or the odd bank allows for load balancing. 5.2.12 sysad to ad addressing when an address is presented on the sysad bus which decodes to a peripheral on the device controller, the address will be conveyed on the ad bus according to table 18. table 18. sysad to ad addressing 1. ad3 and ad2 are not used when addressing 32 or 64-bit devices. device width sysad[24].. sysad[5] sysad[4] sysad[3] sysad[2] sysad[1] sysad[0] 8-bit ad23..ad4 ad3 ad2 badr[2] badr[1] badr[0] 16-bit ad23..ad4 ad3 ad2 badr[2] badr[1] n/a 32-bit 1 ad23..ad4 badr[2] badr[1] badr[0] n/a n/a 64-bit ad23..ad4 badr[2] badr[1] n/a n/a n/a address tclk ale ads* 1 ad[31:0] adstowr = 3 wractive = 3 wrhigh= 3 wractive programmed to 3 ewr owr 3 gt-64011 drives valid data 1 gt-64011 drives valid data 2 cs* 2 cstiming* devrw* notes: 1. assumes dadr11/ads* is programmed to be ads* only. 2. cs* is driven off the same rising tclk* as ale (and ads*). throughout consecutive transactions to the same device, cs* will remain asserted. this is why cs* must always be qualified with cstiming*. 3. ewr[3:0]* and owr[3:0]* are asserted and deasserted from the falling edge of tclk. 4. ready* is asserted on last rising tclk of wractive, therefore, the gt-64011 assumes the device is written to correctly and continues to the next write cycle. 5. ready* is deasserted on the last rising tclk of wractive, therefore, the gt-64011 does not continue to the next write cycle effectly extending the wractive parameter. ewr*/owr* remains asserted. 6. ready* is asserted on the next rising tclk, therefore, the gt-64011 assumes the device has been written to correctly and co ntinues to the next cycle (end of write transaction). effectively, wractive is 4 (instead of the programmed 3). for clarification, if there w as another word to burst, wrhigh would start counting from the rising tclk denoted by 6, not 5. ready* 4 5 6
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 44 revision 1.0 5.3 data latches since both the dram and device controller share the ad bus for data transactions, typical system have multiple devices attached to the ad bus. the GT-64111s ad bus provides +-16ma of drive and is tested to meet all timing requirements with a maximum load of 50pf. as typical dram configurations require multiple chips and often simms which greatly load the bus, in addition to other devices, the capacitive load can easily exceed 50pf. excessive capac- itive loading will make the rise and fall times of the signals driven by the ad bus become much longer and may cause timing violations. the solution to a heavily loaded ad bus is to add latches which act as strong drivers for greater fanout. using external latches also improves timing since data does not need to be sampled precisely on a certain clock edge. instead, the latched data is valid on the bus longer and the window for clocking in the data is wider. this is extremely important with fast page mode dram since data becomes invalid as soon as cas* is de-asserted. without latching the data, the cas* assertion time must be extended to meet the GT-64111s setup and hold requirements. a longer cas* assertion time will degrade the overall system performance. note: latches are required for 64-bit dram or devices. the GT-64111 outputs all of the control signals for a standard 501 bi-directional latch. there is a separate set of latch control signals for both the even and odd banks as shown in table 19. table 19. memory controller latch controls for dram and devices note: the latch signals are always active during dram and device writes. 5.3.1 enabling latch control signals on read transactions enabling the latch signals on dram read cycles is set by bit 18, dramlatch, of the dram configuration register (0x448). this controls the read latch signals for all dram banks. if dramlatch is set to 0, the latch control signals are active on read accesses. if dramlatch is set to 1, the external data latches are transparent in dram read accesses when casrd* is programmed to be one cycle long. if casrd* is programmed to be 2 cycles, the latch enables will always be active regardless of dramlatch setting. enabling the latch signals on device read cycles is set by bit 25, latchfunc, of the device bank parameters registers (0x45c-0x46c). each device bank can be individually configured to have latch control signals active during device reads. if latchfunct is set to 0, the external data latches are transparent on all device read cycles for this particular device bank. if latchfunct is set to 1, the latch control signals are active on read accesses. 5.4 parity checking support each bank of dram and devices can be configured individually for parity checking. this allows the flexibility to desig- nate certain banks for peripherals which support parity checking, and other banks for devices which do not. bit 8 of the dram bank parameters registers (ox44c to 0x458) controls whether the GT-64111 will sample parerr* on dram reads. bit 30 of the device parameters registers (0x45c to 0x46c) controllers whether the GT-64111 will sample par- err* on device reads. parerr* is sampled on the same rising edge of tclk that data is sampled. 1. the latch enable signals will be active on read cycles only if they are set in the dram bank parameters registers or the dev ice bank parameters registers. see section 5.3.1. signal description active cycles 1 asserted from tclk de-asserted from tclk lee, leo latch enable dram reads (if config- ured) rising rising lee, leo latch enable device reads (if config- ured) rising falling lee, leo latch enable dram and device writes rising falling oee*, oeo* output enable dram and device reads (if configured) rising rising oeb output enable dram and device writes rising rising
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 in the case of dram or device writes, parity should be generated by external logic (i.e. 511s). in the case of dram or device reads, parity errors should be detected by external logic. if parity error checking is enabled for a particular bank, and a parity error is detected by the external logic on a cpu read cycle, it will report this error to the GT-64111 via the parerr* pin. on cpu read accesses from a 32-bit device or memory, the GT-64111 will not assert syscmd[4] even if the bank that was accessed has the parity integrity bit set. if a parity error is detected in this case (indicated by par- err*), the GT-64111 will return the data with syscmd[5] asserted and will cause a parity error interrupt. in dma read accesses, detection of a parity error from a bank with the parity integrity bit set, will cause an interrupt. in the case of pci read accesses, the GT-64111 will assert serr* (if unmasked) if the bank that data was read from has the parity integrity bit set, and will assert a parity error interrupt. the GT-64111 will generate and check word (32 bits) parity on data that is read from the pci with compliance to the pci requirements for every transaction. a parity error detection on the pci will cause the assertion of perr*. 5.5 addressing when the cpu reads a block of data from the memory controller, the controller will read it from dram or devices in sub-block order and the GT-64111 will return the data to the cpu in sub block order. for more information about sub block ordering, please see your cpu manual. when a pci master or the dma controller accesses data from the memory controller, data is always addressed lin- early. 5.6 memory interface restrictions 1. if latches are not present, all banks must be programmed to be on the even bus. programming the registers to 64- bit mode or to dynamically controlled latches will result in an error. 2. unless the boot device is 64-bits wide, the boot must be on the even bank. 3. for 8 and 16-bit devices, all device parameters except turnoff (section 5.2.2 - section 5.2.6) must be greater or equal to 3. i.e., acctofirst, acctonext, adstowr, wractive and wrhigh. 4. for 32 and 64-bit devices, the fastest timing parameters (best performance) are as follows: ? acctofirst = 3 ? acctonext = 1 (if latches are transparent) or 2 (if latches are active) ?adstowr = 2 ? wractive = 1 ? wrhigh = 1 5. when working with an 8- or 16-bit configured bank from cpu, a read/write operation can not exceed 64-bits (8 bytes). 6. when working with an 8- or 16-bit configured bank from dma/pci, a read/write operation cant exceed 32-bits (4 bytes). 7. when an erroneous address is issued or a burst operation is performed to an 8- or 16-bit device, the GT-64111 forces an interrupt (unless masked). if a sequence of address misses occurs, there will be no other interrupt prior to resetting the appropriate bit in the cause register and no new address will be registered in the address decode error register (0x470) prior to reading it. 8. when the cpu reads from an address which is decoded in the cpu interface unit as being a hit for cs[2:0]* or cs[4:3]* and decoded as a miss in the dram/device interface unit, the cycle will complete only if ready* is asserted (i.e., driven low). although being a result of improper and inconsistent programming of the address space defining registers, the following 2 workarounds exist: ? ready* should always be asserted (low) when cstiming* is inactive (high). ? if the ready* signal is not needed in the system, the dmareq[0]/ready* pin should either be programmed as
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 46 revision 1.0 ready* and constantly driven active (low) or be programmed as dmareq[0]*.
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 6. pci bus the GT-64111 includes a revision 2.1 compliant pci interface. as a pci device, the GT-64111 can be either a master initiating a pci bus operation or a target responding to a pci bus operation. operation up to 66mhz is supported, as is 3.3v and 5v signalling. 6.1 pci master operation when the cpu/local master or the internal dma machine initiates a bus cycle to a pci device, the GT-64111 becomes a pci bus master and translates the cycle into the appropriate pci bus cycle. supported master pci cycles are: ? memory read ? memory write ? memory read line ? memory write & invalidate ?i/o read ?i/o write ? configuration read ? configuration write ? interrupt acknowledge ? special cycle memory write & invalidate and memory read line cycles are carried out when the transaction accessing pci memory space requests a data transfer equal to the pci cache line size. when the pci cache line size is set equal to 0, the gt- 64111 will never issue memory write & invalidate or memory read line cycles. as a master, the GT-64111 does not issue dual address cycles or lock cycles on the pci. the pci posted write buffer in the GT-64111 permits the cpu/local master to complete cpu-to-pci memory writes even if the pci bus is busy. the posted data is written to the pci device when the pci bus is available. 6.1.1 pci master cpu/local master address space decode and translation cpu/local master access the pci space through the pci memory 0, pci memory 1 and pci i/o decoders in cpu/ local master address space. cpu/local master accesses that are claimed by these decoders are translated into the appropriate pci cycles. the address seen on the cpu/local master bus is copied directly to the pci bus. for example, if and accesses to 0x1200.0040 is programmed to be bridged as a memory read from pci, then the active pci address for this cycle will be 0x1200.0040. access to the full pci space is possible by relocating the cpu/local master pci decoders within cpu/local master space as needed. this relocation can be made transparent to user code by using the memory remapping capabilities of the cpu/local master (mmu or base/bounds function.) 6.1.2 pci master cpu/local master byte swapping all accesses to pci space through the cpu/local master can have the data byte order swapped as the data moves through the GT-64111. byte swapping is turned on via the byteswap bit in the pci internal command register (0xc00.) note: regardless of the setting of byteswap, pci accesses from a pci master to the GT-64111s internal reg- isters or pci configuration registers will not be swapped. 6.1.3 pci master fifos the pci master interface includes a fifo of 8 entries, each 32 bit. during writes to the pci interface, it receives write data from the cpu/local master interface or the dma unit. when the pci bus is granted, the fifo delivers the write data to the target on the pci bus. upon receiving the first 32-bit word from the cpu/local master interface or dma unit, the pci master interface will request the pci bus (if the GT-64111 is not already parked). once granted, the appropriate write cycle is started on the pci bus. during reads, the pci master interface fifo receives read data from the pci bus and delivers it to the cpu/local mas-
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 48 revision 1.0 ter interface or the dma unit. upon receiving the first 32-bit word from the pci target, the data is forwarded to the requesting unit (cpu/local master interface or dma unit). the GT-64111 supports sub-block ordering during cpu/ local master reads, therefore if the original read request address is not aligned to a cache line boundary, the first 32-bit word returned to the requesting unit will be delayed until it is received from the pci target, since reads across the pci bus are linear. the GT-64111 internal architecture allows zero wait-state data transfer over the pci bus (irdy* continuously asserted) during both master reads and writes. 6.1.4 pci master dma the GT-64111s internal dma engines can act as pci bus masters while transferring data to/from the pci bus. the dma engines will only issue memory space read and write cycles. the type of cycle issued follows the same rules as for the cpu/local master. the dma engines can transfer data between pci devices using the on-chip dma fifos for temporary storage. 6.1.5 pci master retry counter retrys detected by the pci master interface are normally handled transparently from the point of view of the cpu/ local master or dma engines. in some rare circumstances, however, a target device may retry the GT-64111 excessively (or forever.) the retry counter can be used to recover from this condition. every time the number of retrys equals the value in the retry counter, the GT-64111 will abort the cycle and send an interrupt to the cpu/ local master. if the cycle was a read, undefined data is returned and the error bit is set in the data command. the retry counter can be disabled by setting the retry count to zero. 6.1.6 cache line size the cacheline in pci configuration register at 0x00c specifies the cache line size. the setting of this register specifies the pci master policy regarding memory read line/memory write & invalidate commands placed on the pci bus. based on the following: ? if cache line size is equal to zero, the master will not issue memory read line/memory write & invalidate commands. ? for cache line sizes greater than zero but less than or equal seven the master will issue memory read line/ memory write & invalidate commands when the transaction-length matches the cache line size. ? for cache line sizes greater than seven, the master will not issue memory read line/memory write & invali- date commands. 6.2 pci target interface the GT-64111 responses to the following pci cycles as a target device: ? memory read ? memory write ? memory read line ? memory read multiple ? memory write and invalidate ?i/o read ?i/o write ? configuration read ? configuration write the GT-64111 will lock a cache line (32-bytes) in the local memory address space when responding to lock sequences on the pci bus. the GT-64111 will not act as a target for interrupt acknowledge, special, and dual address cycles (these cycles will be ignored.)
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 6.2.1 pci target fifos the GT-64111 incorporates dual 32-byte posted write/read prefetch buffers to allow full memory (ad) and pci bus con- currency. the dual fifos operate in a ping-pong fashion, each fifo alternating between filling and draining. when the GT-64111 is the target of pci write cycles, data is first written to one of the fifos. when the first fifo fills up (32 bytes), the data is written to the destination from the first fifo while the second fifo is filled. this ping-pong operation continues as long as data is received from the pci bus. occasionally the pci target interface cannot drain the fifos (i.e. write to local memory) as fast as data is received. this will only happen when access to memory is prevented (possibly by excessive cpu/local master accesses) or when the target memory is particularly slow. in this case, the GT-64111s pci target interface will issue a discon- nect to the pci bus. figure 22: pci target interface ping-pong fifos data 0 data 1 data 2 data 3 data 4 data 5 data 6 data 7 data 0 data 1 data 2 data 3 data 4 data 5 data 6 data 7 dram/device unit fifo b (32-bytes) fifo a (32-bytes) pci bus transaction address ad bus
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 50 revision 1.0 figure 23: pci target interface fifos operational example the target fifos are also used for read prefetch. the memory read multiple (mrm) cycle is the only prefetchable read cycle. in response to any target pci read cycle, the GT-64111 will read an entire cache line (32 bytes) from mem- ory into one of the target fifos. if the read is a memory read multiple, as soon as at least two words are delivered from the fifo to the pci bus, another 32 bytes is prefetched into the second fifo. in this case, the GT-64111 is essentially guessing that mrm cycle will be longer than 32 bytes. in a non-prefetchable read cycle, data is not fetched into the second fifo until after all data from the first fifo is deliv- ered to the pci bus. cycles to internal registers and configuration cycles are non-postable or prefetchable. 6.2.2 pci target address space decode and byte swapping the GT-64111 decodes accesses on the pci bus for which it may be a target by the values programmed into its base address registers (bars). there are two sets of bars: regular bars (in pci function 0) and swap bars (in pci function 1). accesses decoded by the swap bars are passed with to/from the target memory device after converting the endianess of the data (e.g. little-endian to big-endian). accesses decoded by the regular bars, by comparison, are passed without modifying the data to/from the target memory device. the GT-64111 uses a two stage decode process for accesses through the pci target interface. once a pci accesses is determined to be a hit based on the bar comparison, the address is passed to the device unit for sub-decode. for example, base address register 0 in function 0 (bar0) decodes non-byte swapped accesses to the dram controlled by either ras0* or ras1*. the GT-64111 then uses the values programmed into the ras0 low and ras0 high decode registers to determine if the access is to the dram connected to ras0. note that the second stage decoders are shared with the cpu/local master (see cpu/local master address space decode for a nice picture showing this.) on reads, if the target pci address hits based on the bar decode, then misses in the device unit, will return random data. on writes, if the target pci address hits based on the bar decode, then misses in the device unit, the data will be discarded. in both situations, the memout interrupt will be set (bit 1 of the interrupt cause register, 0xc18). further, when the GT-64111 is a pci target and there is a hit in one of the base address registers, the memen/ioen bit of the status and command register (pci config. register 0x04) must be set to 1 in order for the GT-64111 to respond to pci memory/io transactions. if memen/ioen is set to 0 and there is a hit in one of the base address reg- 12 3 fifo b (32-bytes) data 0 data 1 data 2 data 3 data 4 data 5 data 6 data 7 data 0 data 1 data 2 data 3 data 4 data 5 data 6 data 7 dram/device unit fifo a (32-bytes) pci bus fifo b (32-bytes) data 0 data 1 data 2 data 3 data 4 data 5 data 6 data 7 data 0 data 1 data 2 data 3 data 4 data 5 data 6 data 7 dram/device unit fifo a (32-bytes) pci bus fifo b (32-bytes) data 0 data 1 data 2 data 3 data 4 data 5 data 6 data 7 data 0 data 1 data 2 data 3 data 4 data 5 data 6 data 7 dram/device unit fifo a (32-bytes) pci bus data flowing into fifo a from pci. no data flowing into dram yet. 8 words have been posted from pci. fifo a and b "flip". fifo b is now taking data from pci while fifo a drains into dram. 10 words haven been posted. pci bus has completed burst after 10 words. fifo a has drained and now fifo b is draining into dram.
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 isters, the GT-64111 will not respond to memory/io transactions. 6.2.3 tweaking the performance of the target interface the GT-64111 includes special performance tuning features for the pci target interface. the timeout0 and timeout1 registers allow the designer to force the GT-64111 to wait either longer than normal, or shorter than normal, before issuing a retry/disconnect. the timeout0 value sets the number of clocks the GT-64111 will wait for the first data of an access before issuing a retry. the timeout1 value sets the number of clocks the GT-64111 will wait between subsequent data phases during an access before issuing a disconnect. the pci 2.1 specifications sets the maxi- mum for both of these at 16 clocks (timeout0) and 8 clocks (timeout1) repsectively. however, in many systems, espe- cially those with long dram latencies, it may be necessary to bend these restrictions. 1 if you see what appears to be excessive retry/disconnect behavior in your system, try lengthening the timeout0/ 1 values. it may be because there is a lot of memory activity due to the cpu/local master or dma engines, and the pci interface cannot get to the dram within 16 clocks. 6.3 pci synchronization barriers the GT-64111 considers some cycles to be synchronization barrier cycles. in such cycles, the GT-64111 makes sure that at the end of the cycle there remains no posted data within the chip. the target synchronization barrier cycles are lock read and configuration read. if there is no posted data within the GT-64111, the cycle ends normally. if after a retry period there is still posted data, the cycle will be retried. until the ori g- inal cycle ends, any other (different address/command) synchronization barrier cycles will be retried. lock read is a synchronization barrier cycle which lasts during the entire lock period, i.e. when the slave is locked all configuration reads will be retried. also, all cycles addressed to internal registers will be retried until lock ends. the cpu/local master interface treats i/o reads to pci and configuration reads as synchronization barrier cycles as well. these reads will be responded to once no posted data remains within the GT-64111. 6.4 pci master configuration the GT-64111 translates cpu/local master read and write cycles into configuration cycles using pci configuration mechanism #1 (per the pci specification). mechanism #1 defines a way to translate the cpu/local master cycles into both pci configuration cycles on the pci bus, and accesses to the GT-64111s internal configuration registers. the GT-64111 includes two registers: configuration address (at offset 0xcf8) and configuration data (at offset 0xcfc). the mechanism for accessing configuration registers is to write a value into the configuration address register that specifies: ? pci bus number (usually bus 0, the bus attached directly to the GT-64111) ? the device on that bus ? the function number within the device ? the configuration register within that device/function being accessed a subsequent read or write to the configuration data register (at 0xcfc) then causes the GT-64111 to translate that configuration address value to the requested cycle on the pci bus. if the busnum field in the configuration address register equals 0 but the devnum field is other than 0, a type0 access is performed which addresses a device attached to the local pci bus. if the busnum field in the configuration address register is other than 0, a type1 access is done which addresses a device attached to a remote pci bus. the GT-64111 performs address stepping for pci configuration cycles. this allows for the use of the high-order pci ad signals as idsel signals through resistive coupling. 2 table 20 shows devnum to idsel mapping. 1. the pci specification also states that a master may not enforce target rules. in other words, even if the GT-64111 takes lon ger than 16 clocks to return the first data, the master must just wait patiently. 2. resitive coupling is a fancy way of saying hook a resistor from adx to idsel on a given device. look at the galileo-4pb backplane schematics for examples.
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 52 revision 1.0 table 20. devnum to idsel mapping the cpu/local master accesses the GT-64111s internal configuration registers when the fields devnum and busnum in the configuration address register are equal to 0. the GT-64111 configuration registers are also accessed from the pci bus when the GT-64111 is a target responding to pci configuration read and write cycles. note: the cpu/local master interface unit cannot distinguish between an access to the GT-64111 pci configuration space and an access to an external pci device configuration space. this is because both are accessed using an access to the GT-64111 internal space (i.e. configuration data register). when the cpu/local master is operating in big-endian mode, any access to the GT-64111 internal space undergoes byte swapping as all internal registers are lit- tle-endian. with the cpu/local master operating in big-endian mode and the pci byteswap bit (bit [0] @ 0xc00) set to 0 (i.e., swap bytes), bytes will be swapped once for pci configuration accesses intended for the GT-64111 configura- tion space but will be swapped twice for pci configuration accesses intended for devices external to the GT-64111. this requires the software to format write data and interpret read data differently for pci configuration accesses to the GT-64111s registers and configuration accesses through the GT-64111 to an external device. important: the configuration enable bit (configen) in the configuration address register must be set before the configuration data register is read or written. failure to do this will lock up the GT-64111 and require a reset to recover. 6.4.1 special cycles and interrupt acknowledge a special cycle is generated whenever the configuration data register is written to while the configuration address register has been previously written with 0 for busnum, 1f for devnum, 7 for functnum and 0 for regnum. an interrupt acknowledge cycle is generated whenever the interrupt acknowledge (0xc34) register is read. 6.5 target configuration and plug and play the GT-64111 includes all of the required plug and play pci configuration registers. these registers, as well as the gt- 64111s internal registers, may be accessed from both the cpu/local master and the pci bus. the GT-64111 acts as a two function device when being configured from the pci bus. the base address registers available in function 0 are used to decode accesses for which there is no byte swapping; function 1 is used to decode byte swapped addresses. all other registers are shared between function 0 and function 1. 6.5.1 plug and play base address register sizing systems adhering to the plug and play configuration standard determine the size of a base address registers decode range by first writing 0xffff.ffff to the bar, then reading back the value contained in the bar. any bits that were unchanged (i.e. read back a zero) indicate that they cannot be set and are therefore not part of the address compari- son. with this information the size of the decode region can be determined. 1 the GT-64111 responds to bar sizing requests based on the values programmed into the bank size registers. these devnum[15:11] pad[31:11] 00001 0 0000 0000 0000 0000 0001 00010 0 0000 0000 0000 0000 0010 00011 0 0000 0000 0000 0000 0100 00100 0 0000 0000 0000 0000 1000 - - - - - - 10101 1 0000 0000 0000 0000 0000 00000, 10110 - 11111 0 0000 0000 0000 0000 0000
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 registers can be loaded automatically after reset from the system rom (see below). 6.5.2 multi-function device, swap bars if one of the swap base address registers is enabled after rst* (see reset configuration), the GT-64111 will be con- figured as a multi-function device (bit 7 in the header type register set to 1, 0xe). to access any of the swap base address registers, a configuration access addressed to function #1 should be used with the appropriate register offset. if a different offset other than 0x010, 0x014, or 0x01c is accessed when specifying function #1, the transaction will access the corresponding offset register in function #0. configuration transactions to any other function number will be ignored. if none of the swap base address registers are enabled after rst*, the GT-64111 will be configured as a single func- tion device (bit 7 in the header type register set to 0, 0xe) and the function #1 configuration registers will be unaccess- able. note: if the GT-64111 is programmed as a single function device, the swap base address registers can still be pro- grammed by a configuration access addressed to function #1 and the appropriate register offset. but, any pci access which is a hit in these swap base address registers will be ignored by the GT-64111. 6.5.3 pci autoconfiguration at reset eight pci registers can be automatically loaded after rst*. autoconfiguration mode is enabled by asserting the dmareq[3]* low on rst*. any pci transactions targeted for the GT-64111 will be retried while the loading of the pci configuration registers is in process. it is highly recommended that all pc applications utilize the pci autoconfiguration at reset feature. the auto- load feature can be easily implemented with a very low cost epld. galileo provides sample epld equations upon request. (you can always pull the epld off your final product if you find there are no issues during testing.) note: the GT-64111s default class code is 0x0580 (memory controller) which is a change from the gt-64011. the gt-64011 used the class code 0x0600 which denotes host bridge. some pcs refuse to configure host bridges if they are found plugged into a pci slot (ask the bios vendors why...). the memory controller class code does not cause a problem for these non-compliant bioses, so we used this as the default in the GT-64111. the class code can be reporgrammed in both devices via autoload or cpu register writes. 1. please refer to the pci specification for more information on the bar sizing process.
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 54 revision 1.0 the pci register values are loaded from the rom controlled by bootcs* are shown in table 21, below. table 21. pci registers loaded at reset 6.5.4 expansion rom functionality the GT-64111 implements the pci expansion rom as required by pc boot devices. the pci expansion rom func- tionality is enabled by strapping dadr[2] low at reset ( see reset section.) if the pci expansion rom is disabled, expansion rom register (offset 0x30 of pci configuration space) acts as reserved register and returns all 0s when read. when the expanion rom is enabled by the pin strapping option, the pci expansion rom bar appears magically in the GT-64111s pci configuration header. however, the expansion rom decoder shares functionality with the cs3*/ bootcs* resource. in normal operation (i.e. after the bios initialization is complete), the expansion rom is disabled via bit 0 in the expansion rom bar. during bios boot, however, the bios turns on the expansion rom decoder by setting bit 0. when the expansion rom decoder is on the following happens: ? the pci target will act as if the timeout0 and timeout1 msbs are 1 (which means initial value of 0x8f and 0x87 respectively). this is done to allow for the long default access time from 8-bit boot roms. ? the device unit will bypass it's address decoding for all transactions from pci that are targeted to expansion rom or cs[3]/bootcs* . all of these transactions will assert cs[3] regardless of the actual address. ? the GT-64111 will act this way as long as bit[0] of expansion rom register is set to 1 (it's the bios responsibil- ity to clear this bit when it is done executing/probing the expansion rom. (if for any reason the bios does not clear bit[0] of expansion rom bar, you can still program this bit to 0 from cpu/local master side.) 6.6 pci parity support GT-64111 implements all parity features required by pci spec, including par,perr* and serr* generation and checking. as an initiator, GT-64111 generates even parity on par signal for address phase and data phase of write transaction. it samples par on data phase of read transaction. if it detects bad parity and perren bit in status and command config- uration register is set, it asserts perr*. as a target, GT-64111 generates even parity on par signal for data phase of a read transaction. it samples par on address phase and data phase of write transaction. if it detects bad parity and perren bit in status and command con- figuration register is set, it asserts perr*. GT-64111 might asserts serr* if one of the following conditions occur: ? detect bad address parity as a target ? detect bad data parity on a write transaction as a master (detects perr* asserted) ? detect bad data parity on a read transaction as a master ? detect ecc error on read from sdram or device ? performs master abort register offset boot device address device and vendor id 0x000 0x1fffffe0 class code and revision id 0x008 0x1fffffe4 subsystem device and vendor id 0x02c 0x1fffffe8 interrupt pin and line 0x03c 0x1fffffec ras[1:0]* bank size 0xc08 0x1ffffff0 ras[3:2]* bank size 0xc0c 0x1ffffff4 cs[2:0]* bank size 0xc10 0x1ffffff8 cs[3]* & boot cs* bank size 0xc14 0x1ffffffc
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 ? detect target abort serr* will be asserted if serren bit in status and command configuration register is set to 1 and if serr* is not masked through serr mask register. 6.7 pci bus/device bus/cpu/local master clock synchronization the pci interface is designed to run asynchronously with respect to the ad and cpu/local master buses. the syn- chronization delay between these two clock domains can be reduced, however, by running the interfaces in synchro- nized mode. an example would be having the cpu/local master/ad buses running at 66mhz and the pci bus running at a 33mhz frequency that was derived from the 66mhz. latency through the GT-64111 is reduced to a minimum when synchronized mode is selected. the synchronization mode is set via the syncmode bits in the pci internal command register (0xc00). note: pclk frequency must be smaller than tclk frequency by at least 1mhz. please see ac timing section for more information. 6.8 66mhz capability bit the 66mhz capability bit in the pci header is sampled from an external pin at reset. note that the state of this bit does not in any way affect the speed of the pci interface. it only acts as an advertisement to other pci devices (or the host cpu) that the GT-64111 is capable of running at 66mhz. please see the reset strapping options section for more details. 6.9 universal pci vio pin the vio pin is used by the GT-64111 to determine the signalling voltage of the pci interface (3.3v or 5v). this pin is normally connected to pin 88 on side b of a standard pci connector when used in a pci add-in card application. note: the vio pin on the GT-64111 was used as the vref pin on the gt-64011. vref is used on the gt-64011 to set the voltage for the cpu interface to be either 3.3v or 5v. 6.10 pci interface restrictions note: no pci access should be attempted before 6 pclk cycles following deassertion of rst* have expired. 6.10.1 master a) latency count, as specified in lattimer (pci configuration register 0x00c), should not be programmed to less than 6. 6.10.2 slave a) the set bits in the bank size registers must be sequential. b) when the slave is locked, in order to prevent a deadlock, all transactions to internal registers (i/o or memory cycles) are not supported (retry will be issued). c) timeout0 (pci internal register 0xc04), should not be programmed to less than 2. 6.10.3 master and slave a) pclk frequency must be smaller than tclk frequency by at least 1mhz.
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 56 revision 1.0 7. dma controller the GT-64111s dma controller consists of four independent channels. the dma channels are used to optimize sys- tem performance by moving large amounts of data without cpu intervention. rather than having the cpu read data from one source and write it to another, each dma channels can be programmed to automatically transfer data inde- pendent of the cpu. this frees the cpu and allows it to continue executing other instructions simultaneous to the movement of data. each dma channel can move data between dram and devices, between devices on the pci bus, or between dram and devices, and devices on the pci bus. the four dma channels request to execute a dma and if there are simulta- neous requests, a programmable arbiter which dma channel will be serviced (see section 7.5 for more information about the dma arbiter). all dma transfers use an internal 32-byte fifo for moving data (see figure 24). data is trans- ferred from the source into the internal fifo, and from the internal fifo to the destination. each dma channel can be programmed to move up to 64 kbytes of data per transaction. the burst length of each transfer of dma can be set from 1 to 32 bytes. accesses can be non-aligned both in the source and the destination. figure 24: dma controller dma fifo 8 x 32 bit dma arbiter byte count 0 source address 0 destination address 0 pointer to next record 0 byte count 1 source address 1 destination address 1 pointer to next record 1 byte count 2 source address 2 destination address 2 pointer to next record 2 byte count 3 source address 3 destination address 3 pointer to next record 3 data 7 data 6 data 5 data 4 data 3 data 2 data 1 data 0 channel 0 channel 1 channel 2 channel 3 dram/device controller pci dram/device source data pci source data dram/device controller pci pci destination data dram/device destination data read data from soruce address write data to destination address
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 7.1 dma channel registers each dma channel record consists of the following data fields which can be written by the cpu, pci, or dma control- ler in the process of fetching a new record from memory: ? byte count (0x800 - 0x80c). this register is programmed with a 16-bit number which contains the number of bytes of data that this channel must dma. the maximum number of bytes which a the dma channel can be configured to transfer is 64k. this register will decrement at the end of every burst of transmitted data from source to destination. when the byte count register is 0, the dma transaction is finished. ? source address (0x810 - 0x81c). this register is programmed with a 32-bit address. this is the source address for data and can be from the dram, device or from pci. this register will either increment, decre- ment, or hold the same value according to bits 3:2 of the channel control register (see section 7.2.2). ? destination address (0x820 - 0x82c). this register is programmed with a 32-bit address. this is the destina- tion address for data and can be to the dram/device or to pci. this register will either increment, decrement, or hold the same value according to bits 5:4 of the channel control register (see section 7.2.3). ? pointer to the next record (0x830 - 0x83c). the register contains a 32-bit address where the values for the next dma channel record can be loaded for chained operation. this can be from the dram/device controller or from pci. the byte count, source address, and destination address must be located at sequential addresses. this register is only used when the channel is configured for chained mode (see section 7.2.5). a value of 0 (null) for this register indicates this is the last record in the chain. see below for more information about chained dma mode. 7.2 dma channel control register (0x840 - 0x84c) each dma channel has its own unique control register where certain dma modes can be programmed. following are the bit descriptions for each field in the control register. 7.2.1 addcontrol[1:0], GT-64111-p-1 only addcontrol[1:0] are for source and destination address control for pci devices (regardless of the cpu interface unit's address decoding). in other words, the dma will access pci memory regardless of the results of the address decoding in the cpu interface unit if the proper bit is set. table 22. setting addcontrol[1:0] 7.2.2 srcdir, bits[3:2] the srcdir field contains information about how the source address for the dma transfer is handled. these bits, if set to 00 (default), will automatically increment the source address. if set to 01, the source address will automatically decrement. if set to 10, the source address will remain constant throughout the dma burst. 11 is a reserved setting and these bits must not be set to this value. 7.2.3 destdir, bits[5:4] the destdir field contains information about how the destination address for the dma transfer is handled. these bits, if set to 00 (default), will automatically increment the destination address. if set to 01, the destination address will auto- matically decrement. if set to 10, the destination address will remain constant throughout the dma burst. 11 is a reserved setting and these bits must not be set to this value. addcontrol[0] addcontrol[1] source destination 0 0 cpu address space cpu address space 1 0 pci memory space cpu address space 0 1 cpu address space pci memory space 1 1 pci memory space pci memory space
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 58 revision 1.0 7.2.4 dattranslim, bits[8:6] the dattranslim field contains the burst limit of each data transfer. the burst limit can vary from 1 byte to 32 bytes in modulo-2 steps (i.e. 1, 2, 4,..., 32) as shown in table 23. table 23. setting datatranslim 7.2.5 chainmod, bit 9 chainmod determines whether this channel is set in chained mode or not. the default setting of 0 enables chained mode for the channel. therefore, at the completion of a dma transaction, the pointer to next record register provides the address of a new dma record. if this register contains a value of 0 (null), this indicates that this is the last record in the chain. in chained mode (bit 9 set to 0), a channel can be enabled by two different methods. 1. the channel records parameters for the current transaction (byte count, source, destination, and next record pointer) should be initialized in dram/device memory space or pci devices. the address of the first record should be initialized by writing it to the next record pointer register of the channel. the channel should be enabled by setting chanen to 1 (see section 7.2.8), and setting fetnexrec (see section 7.2.9) to 1. setting these two bits can be completing during the same write or fetnexrec should be set to 1 on the first write and then the dma can be initiated by setting chanen to '1' on another write. if in block mode, the dma will start once the particular chan- nel has been arbitrated for. if in demand mode, the dmareq* must be asserted and then the dma will start once the particular channel has been arbitrated for. 2. the channels records parameters for the current transaction (byte count, source, destination, and next record pointer) should be initialized in the proper dma channel registers. in block mode, the dma can be initiated by set- ting chanen to '1' and the dma will start once the particular channel has been arbitrated for. if in demand mode, the dmareq* must be asserted and then the dma will start once the particular channel has been arbitrated for. fetching the data for the next record (i.e. loading byte count, source, destination, and next record pointer registers) is not dependent on dmareq*. this action will occur automatically as long as the channel is enabled and fetnexrec is set to 1 or the byte count has reached a terminal count and the next record pointer is not null. see figure 25 for a diagram of chained mode dma. if chainmod is set to 1, chained mode is disabled. note that in non-chained mode the byte count, source, and destination registers should be initialized prior to enabling the chan- nel. 7.2.6 intmode, bit 10 intmode controls when this channel asserts the dmacomp (dma complete) interrupt. the default setting of 0 sets the channel to assert the dmacomp interrupt every time the dma byte count reaches 0. if the channel is set to chained mode, and intmode is set to 1, the dmacomp interrupt will only be asserted when both the pointer to next record register has a null value and byte count is 0. if chained mode is disabled, the setting of intmode is irrelevant and dmacomp interrupt will be asserted every time the byte count reaches 0. bits 8:6 transfer limit of each dma access 101 1 byte 101 2 bytes 000 4 bytes 001 8 bytes 011 16 bytes 111 32 bytes
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 7.2.7 transmod, bit 11 transmod indicates whether the channel is set to operate in demand mode or block mode. the default setting of 0 set the channel to operate in demand mode where dma accesses are initiated by externally asserting one of the four dmareq[3:0]* pins. if transmod is set to 1, the channel is set to operate in block mode where dma accesses are ini- tiated by setting chanen, bit 12. in block mode, the dmareq* lines are ignored. 7.2.8 chanen, bit 12 chanen can enable or disable the dma channel. when chanen is set to 0, the channel is disabled. when chanen is set to 1, the dma is initiated based on the current setting loaded in the channel record (i.e. byte count, source address and destination address). note that the dma channel can be enabled or disabled via chanen if the channel is in demand or block mode. 7.2.9 fetnexrec, bit 13 fetnexrec is a field which is only meaningful when chained mode is enabled for the channel. setting this bit to 1 will force a fetch of the next record based on the value in the pointer to next record register. this bit can be set even if the current dma has not yet completed. this bit is reset back to 0 after the fetch of the new record is complete. 7.2.10 dmaactst, bit 14 (read only) dmaactst is a read only field and can be polled to see the dma activity status of the channel. if this bit is set to 0, the channel is not active. if this bit is set to 1, the channel is active. figure 25: chained mode dma 7.3 restarting a disabled channel (previously active) in non-chained mode, chanen should be set to 1. gt-64010 channel 0 dma registers byte count (bytect) source address (srcadd) destination address (destaddr) next record pointer (nextrecptr): 0x10 bytect srcadd destaddr nextrecptr: 0x100 0x10 0x14 0x18 0x1c x x x x 0x100 0x104 0x108 0x10c transfer #1 transfer #2 transfer #n bytect srcadd destaddr nextrecptr: y bytect srcadd destaddr null pointer: 0x0
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 60 revision 1.0 in chained mode, the software should find out if the first fetch took place. if it did, only chanen should be set to 1. if it did not, the fetnexrec should also be set to 1. 7.4 reprogramming an active channel to reprogram an active channel, the channel should first be disabled by setting chanen to 0. then it must be assured that the channel is no longer active (for example by polling the dmaactst of the channel). new dma parameters should be programmed prior to re-enabling the channel via setting chanen to 1. 7.5 arbitration the dma controller has a programmable arbitration scheme between its four channels. the channels are grouped into two groups, one group includes channel 0 and 1, and the other group includes channels 2 and 3. the channels in each group can be programmed to have priority so that a selected channel has the higher priority, or to have the same prior- ity in round robin. the priority between the two groups can be programmed in a similar way so that a selected group has a higher priority, or to have the same priority in round robin. the priority scheme has additional flexibility with the programmable priority option. with the priority option the dma bandwidth allocation can be divided in a fairer way. for example, if the prioopt bit is set to 0 and the priogrps field is set as 10, the requesting devices will get the dma in the order 0,1,2,0,1,3,0,1,2,0,1,3,..... (assuming that priochan1/0 and priochan3/2 are set to round robin), while if the prioopt bit is set to 1 the requesting devices will get the dma in the order 0,1,0,1,0,1,2,3,2,3,2,3,..... the dma arbiter control register can be reprogrammed any time regardless of the channels status (active or not active). some arbitration examples follow to facilitate the understanding of this register are shown in table 24. table 24. channel arbitration examples 7.6 dmareq[3:0]* the dmareq[3:0]* input pins are asserted by an external device to request a dma transfer in demand mode. the dmareq* should be asserted as long as the transfer initiator has at least datatranslim of bytes to provide (in case that it is the source) or as long as it has space to absorb at least datatranslim of bytes (in case that it is the destina- tion). the dmareq* should be deasserted by the source when the transfer initiator sees that it does not have at least datatranslim of bytes to provide (i.e. fifo empty). dmareq* should also be deasserted by the destination when the it does not have enough space to absorb at least datatranslim of bytes (i.e. fifo full) and dmaack* is asserted low. # of requesting channel example channels arbiter control register value channel service order 4 all 0x40 0,2,1,3,0,2,1,3,..... 4 all 0x0 0,1,2,3,0,1,2,3,..... 3 0,1,2 0x40 0,2,1,2,0,2,1,2,..... 3 0,1,2 0x0 0,1,2,0,1,2,0,1,2,..... 4 all 0x45 1,3,1,3,1,3,.....,0,2,0,2,0,2,...... 4 all 0x5 1,0,3,2,1,0,3,2,1,0,3,2,..... 3 0,1,2 0x45 1,2,1,2,1,2,.....,0,0,0,0,0,0,..... 3 0,1,2 0x5 0,1,2,0,1,2,..... 4 all 0x55 3,3,3,3,3,3,2,2,2,2,2,1,1,1,1,0,0,0,...... 4 all 0x15 3,2,1,3,2,0,3,2,1,3,2,0,..... 3 0,1,2 0x55 2,2,2,2,1,1,1,1,0,0,0,0,..... 3 0,1,2 0x15 2,1,2,0,2,1,2,0,..... 3 0,2,3 0x55 3,3,3,...,2,2,2,...,0,0,0,..... 3 0,2,3 0x15 3,2,0,3,2,0,3,2,0,.....
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 the dmareq* is sampled on every clock cycle but it influences arbitration only in the dma arbitration cycle or when all channels are idling. the dma arbitration cycle is the cycle in which the destination unit inside the GT-64111 acknowl- edges the last written data from the dma unit. 7.7 dmaack[3:0]* the dmaack[3:0] output pins are asserted by the GT-64111 to indicate that a current dma request is being serviced. the dmaack* is asserted only when the GT-64111 accesses a device. it is asserted when ale is asserted and should be qualified with cstiming*. 7.8 design information the following sections contain more detailed information about designing with GT-64111s dma controller. the follow- ing definitions are used throughout this section: 1. device: a device located on the memory bus mapped to one of the GT-64111s chip selects (including bootcs). 2. pci agent: any device located on the pci bus. 3. dram: dram memory located on the memory bus. 7.8.1 dma in demand mode demand mode is especially designed for transferring data between memory (device, dram, pci agent) and a device. this is because the dmaack* is asserted only when the GT-64111 is accessing a device. in this mode the transfer ini- tiator (usually a device) asserts dmareq* to signal the GT-64111 that a new dma transfer should begin. as an acknowledgment response, the GT-64111 asserts the dmaack* to signal that the asserted dmareq* is currently being processed. in each dma transfer, the dma attempts to read the amount of datatranslim from the source address and writes it to destination address. in the source direction, at the beginning and end of the dma, there may be less than datatrans- lim transfers if the address is not aligned or the remaining byte count to be transferred is smaller then the datatrans- lim. in the destination direction, the dma writes all data that was read from the source to the destination. this may happen in two dma accesses if the destination address is not aligned. the channel will stay active until the byte count reaches the terminal count or until the cpu disables the channel. note that if the dmareq* is always asserted, then this is equivalent to transfer data in block mode. 7.8.1.1 demandmode dma examples/recommendations source: dram/pci, destination: dram/pci in demand mode, then dmaack* should be externally generated (i.e. polling accesses of the GT-64111 to certain addresses). typically, in this case it is better to use blockmode because memory is typically always ready and dmaack* is never asserted. source: device, destination: dram or pci the device transfer initiator asserts dmareq* when it has at least datatranslim number of bytes to provide. it should deassert the dmareq* when no more data is ready and dmaack* is asserted. even if another master (like a pci mas- ter) drives the dmareq* then the dmaack* can signal to that master that the GT-64111 is currently accessing the device for read. note that dmaack* must always be qualified with cstiming*. source: dram or pci, destination: device the device transfer initiator asserts a dmareq* when it can absorb datatranslim number of bytes to be written to it. even if another master drives the dmareq* then the dmaack* can signal the master that the GT-64111 is currently accessing the device for write.
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 62 revision 1.0 7.8.2 dma in block mode in block mode no hand shake signals are used to initiate dma transfers. the dma unit will complete the transfer once the cpu has programmed the dma and enabled it. 7.8.3 non-chain mode in non-chain mode the cpu or pci master initiates the dma channel parameters (source, destination byte count and command registers).the dma will start to transfer data after the enable bit in the command register is set to 1. the dma remains in an active state until the byte count reaches a terminal count or until the channel is disabled. 7.8.4 chain mode in chain mode the dma channel parameters (source, destination byte count and pointer to next record) are read from records located in memory, device or pci. the dma channel stays in the active state until pointer to next record is null and the byte count reaches the terminal count. in this mode, an interrupt can be asserted every time the byte count reaches the terminal count or when both the byte count reaches the terminal count and the pointer to next record is null. 7.8.5 dynamic dma chaining dynamic chaining is when dma records are added to a chain which a dma channel is actively working on. the main issue is to synchronize between when the GT-64111 reads the last chain record (the null pointer) to the time the cpu changes the current last dma record. following is an algorithm which provides this synchronization mechanism. 1. prepare the new record. 2. change the last record's pointer to next record to point to the new record. 3. read the dma control register. if the dmaactst bit is 0 (not active) { update the pointer to next record in the GT-64111 and assert the fetnexrec bit } else { read the pointer to next record GT-64111. if it's equal to null { mark (by using a flag or something) that in the next dma chain complete interrupt you'll need to - [[[[{ update the nrp register in the gt-64010 and write the fetch next record }]]]] } } 7.9 dma restrictions 1. transfers of less than 4 bytes are not supported. 2. when source or destination address is decremented, both addresses should be word-aligned (that is, a1 and a0 should be both zero), and byte count should be a multiple of 4 (this applies for burst limits greater than 4 bytes). 3. when the burst limit is less than 4 bytes, no decrement mode (source or destination) is not supported.
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 4. when using the address hold option in the source direction (see section 7.2.2), the source address should keep the following rules: ? word-aligned if burst limit is greater or equal to 4 bytes. ? bits [1:0] equal to 00, 01 or 10 if burst limit is equal to 2 bytes. ? no restriction for burst limit equal to 1 byte. 5. when using the address hold option in the destination direction (see section 7.2.3), the following rules should be kept: ? both source and destination addresses should be word-aligned if burst limit is greater or equal to 4 bytes. ? bit [0] of both source and destination addresses should be equal to 0 if burst limit is equal to 2 bytes. ? no restriction for burst limit equal to 1 byte. 6. fly-by transfers are not supported. 7. records addresses must be a multiple of 16 bytes. 8. if the destination is a device and if datatranslimit is smaller or equal 4 bytes, the dmaack* asserts during the same cycle as the arbitration cycle. therefore, dmareq*, which is typically de-asserted based on the assertion of dmaack*, is not seen in the dma arbitration cycle. so although the device does not want to be accessed, a new transfer may begin. ? if datatranslimit is bigger then 4 bytes then there is no problem. in this case, it is recommended to have a device that can accepts bursts. ? a solution when using one channel only and datatranslim is less equal to 4 is as follows: ? state a: the first request should be issued after the channel is enabled and the device has enough room for datatranslim. dmareq* should be asserted for 1 cycle and then deasserted. ? state b: while dmaack* is asserted, if the device has enough room for data, assert the dmareq* for 1 cycle and then deassert the request. remain in state b. if the device has no room for data then do not assert the dmareq*. go to state a. ? for 16-bit devices, use 4 byte source aligned addresses for data in dram, and device destination addresses aligned to 4 bytes + 2 while datatranslim = 4 bytes.
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 64 revision 1.0 8. timer/counters there are three 24-bit wide and one 32-bit wide timer/counter on the GT-64111. each one can be selected to operate as a timer or as a counter. in counter mode, the counter will count down to terminal count, will stop and issue an inter- rupt. in timer mode, it will count down, will issue an interrupt on terminal count, and will reload itself to the programmed value and continue to count. reads from the counter or timer are done from the counter itself, while writes are to its register. for example, note that even though the registers are programmed to an initial value of 0 the counters will read 0xffffff. in order to reprogram a timer/counter, it should first be disabled, then it should be loaded with a new value and after that it should be enabled as appropriate (counter or timer). note: there are no external input pins for enable/disable nor are there any output timer pins on the GT-64111.
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 9. interrupt controller the GT-64111 includes an interrupt controller that routes internal interrupt requests to both the cpu/local master and the pci bus. the interrupt controller ors all internal interrupt sources and asserts an interrupt to the cpu/local master or to the pci when one or more internal interrupts are asserted. there is one cause register and two mask registers. the cause register has one bit for each interrupt source. if the source asserts an interrupt, its respective bit in the cause register will be set. this bit can be read by the cpu/local master or from the pci bus. the interrupt is acknowledged by the cpu/local master or by the pci bus by resetting its bit in the cause register (writ- ing zero to the specific bit and one to all other bits). one exception for the above is the cpuint ([25:21] and pciint ([29:26])) which are used by the pci to generate interrupt to the cpu and vice versa. these are set by writing zero from the interrupt originating side and cleared by writing zero from the interrupt destination side. each interrupt source has one mask bit in the cpu/local master mask register and one bit in the pci mask register. a zero in the cpu/local master mask register bit will mask the interrupt from asserting an interrupt to the cpu/local master. a zero in the pci mask register bit will mask the interrupt from asserting an interrupt to the pci. intsum in the interrupt cause register is the logical or of bits[29:1], regardless of the mask registers values. this is in order to be notified via polling if any interrupt occurred within the GT-64111. therefore, bit[0] of both the cpu/local master mask and pci mask registers is read-only 0. cpu/local master intsum in the interrupt cause register is the logical or of bits[29:26,20:1], masked by bits[29:26,20:1] of the cpu/local master mask register. therefore, bits[25:21] of the cpu/local master mask register, being non-relevant to interrupts directed to the cpu/local master, are read-only 0. also bits[31:30], being summaries, are read-only 0. pciintsum in the interrupt cause register is the logical or of bits[25:1], masked by bits[25:1] of the pci mask register. therefore, bits[29:26] of the pci mask register, being non-relevant to interrupts directed to the pci, are read-only 0. also bits[31:30], being summaries, are read-only 0.
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 66 revision 1.0 10. reset configuration the GT-64111 must acquire some knowledge about the system before it is configured by the software. special modes of operation are sampled on reset in order to enable the GT-64111 to function as required. certain pins must be pulled up or down (4.7k ohm recommended) externally to accomplish this. the following configuration pins are contin- uously sampled from rst* assertion until 3 tclk cycles after rst* is deasserted. pin configuration function interrupt*: endianess 0 - 1 - big endian data format little endian data format dadr[11:10]: device boot bus width 00 - 01 - 10 - 11 - 8 bits 16 bits 32 bits 64 bits dadr[9]: leadre/dmareq[2]* selection 0 - 1 - dmareq[2]* leadre dadr[8]: oeb polarity 0 - 1 - active low active high dadr[7]: external latches presence 0 - 1 - latches are present system without latches dadr[6]: enable/disablecs[2:0] pci bar for address matching and size response 0 - 1 - enable disable dadr[5]: dmareq[1]*/parerr* selection 0 - 1 - dmareq[1]* (no parity) parerr* dadr[4]: dmareq[0]*/ready* selection 0 - 1 - ready* dmareq[0]* dadr[3]: enable/disable cs[3] & bootcs pci bar for address matching and size response 0 - 1 - enable disable
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 notes: 1. dadr[9] should be pulled low whenever leadre is not used in the system (e.g., dram is not operating in decre- ment mode). 2. if autoload enable is sampled low during reset, device and vendor id[31:0], class code and revision id[31:0], sub- system id and subsystem vendor id[31:0], interrupt pin, interrupt lines[15:0], ras[1:0]* bank size, ras[3:2]* bank size, cs[2:0]* bank size, cs[3] & bootcs* bank size will be autoloaded starting from address 0x1fff.ffe0. 3. if either dadr[1] or dadr[0] is sampled 0 on rst*, the GT-64111 will be initialized as a multi-function device (bit 7 in the header type register set to 1, 0xe). 4. if a pci bar is disabled for address matching and size response, a pci configuration read to this register will return 0x0. pci configuration writes to this bar will remain valid (i.e. the value of the configuration write will remain in the reg- ister). but, if a disabled bar is programmed with a base address, and there is a pci address on the pad[31:0] bus which hits in the disabled bar, the GT-64111 will ignore this transaction as if there was no hit (i.e. devsel* will not 1. this pin was a vss on the gt-64011. dadr[2]: enable pci expansion rom 0 - 1 - enable disable dadr[1]: enable/disable swapped ras[3:2] pci bar for address match- ing and size response 0 - 1 - enable disable dadr[0]: enable/disable swapped cs[3] & boot cs pci bar for address matching and size response 0 - 1 - enable disable dmareq[3]*: autoload enable 0 - 1 - enable disable dmareq[1]*/ parerr*: enable/disable internal registers i/o mapped pci bar for address matching and size response 0 - 1 - enable disable dmareq[0]*/ ready*: enable/disable ras[3:2] pci bar for address matching and size response 0 - 1 - enable disable pin 15: enable 66mhz pci bus capability in pci header 1 0 - 1 - 33mhz pci bus operation indicated 66mhz pci bus operation indicated pin configuration function
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 68 revision 1.0 be asserted). 5. if a pci bar is disabled for address matching and size response, a bios query of this disabled bar for its size will respond with 0x0. in other words, if the disabled pci bar is first writen to with 0xffff.ffff, and then the disabled pci bar is read, the data returned will be 0x0.
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 11. connecting the memory controller to dram and devices in order to connect the memory (dram and devices) correctly, it is necessary to properly choose the system configu- ration. the GT-64111 supports two main configuration modes: without data latches or with data latches. 11.1 working without data latches only systems that do not have 64-bits wide memories can work without latches. in this configuration the only external latch required is for device control and address (uni-directional 373 type). notes: 1. dev_adr[21:0] is the output of the control latch connected to ad[23:2], sampled by ale. 2. regardless of data endianess, ecas[0]* and ewr[0]* always correspond to ad[7:0] ecas[1]* and ewr[1]* always correspond to ad[15:8]. ecas[2]* and ewr[2]* always correspond to ad[23:16]. ecas[3]* and ewr[3]* always correspond to ad[31:24]. 3. for load balancing, one can connect owr[3:0]* and ocas[3:0]* as well. connection memory width connect... to... dram address 32-bit dadr[11:0] dram address pins device address 1 32-bit 16-bit {dev_adr[21:2],dadr[2:0]} {dev_adr[21:0],dadr[2:1]} device address pins device address pins 8-bit {dev_adr[21:0],dadr[2:0]} device address pins dram data 2,3 32-bit ad[31:0] dram data pins device data 2,3 32-bit ad[31:0] device data pins 16-bit ad[16:0] device data pins 8-bit ad[7:0] device data pins device control 32-bit or less ad[31:0] ale control latch bit[0] output control latch bit[1] output control latch bit[23:2] outputs control latch bit[27:24] outputs control latch bit[31:28] outputs control latch inputs control latch le becomes bootcs* becomes devrw* becomes dev_adr [21:0] becomes dmaack[3:0]* becomes cs[3:0]*
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 70 revision 1.0 11.2 working with data latches 11.2.1 64-bit dram notes: 1. system supports decrement. 2. system is little endian without decrement. 3. system is big endian without decrement. 4. signals can be optionally buffered. 5. be careful if oeb is programmed at reset to have reverse polarity. 6. sysadc[3:0] from the cpu/local master too, if parity is supported. 7. regardless of endianess, ecas[0]* and ocas[0]* always corresponds to sysad[7:0] and ad[7:0]. ecas[1]* and ocas[1]* always corresponds to sysad[15:8] and ad[15:8]. ecas[2]* and ocas[2]* always corresponds to sysad[23:16] and ad[23:16]. ecas[3]* and ocas[3]* always corresponds to sysad[31:24] and ad[31:24]. connection memory width connect... to... dram address 1 64-bit dadr[11:0] dadr[11:0] even latch outputs odd latch outputs leadre leadro even latch inputs odd latch inputs even dram address pins odd dram address pins even latch le odd latch le dram address 2 64-bit dadr[11:0 ]4 dadr[11:0] odd latch outputs leadro even dram address pins odd latch inputs odd dram address pins odd latch le dram address 3 64-bit dadr[11:0] 4 dadr[11:0] even latch outputs leadro odd dram address pins even latch inputs even dram address pins even latch le dram data (latched) 7 64-bit ad[31:0] even latch i/os b side 0 lee oee* oeb 5 ad[31:0] odd latch i/os b side 0 leo oeo* oeb 5 even latch i/os a side even bank data pins even latch clkab and clkba even latch leab and leba even latch oeba* even latch oeab odd latch i/os a side odd bank data pins odd latch clkab and clkba odd latch leab and leba odd latch oeba* odd latch oeab
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 11.2.2 32-bit dram connecting 32-bit dram is the same for the odd and even bank. it is optional to have one bidirectional buffer. notes: 1. example shows even bank choice, but odd bank can be selected instead. 2. regardless of endianess, ecas[0]* always corresponds to sysad[7:0], and ad[7:0]. ecas[1]* always corresponds to sysad[15:8], and ad[15:8]. ecas[2]* always corresponds to sysad[23:16], and ad[23:16]. ecas[3]* always corresponds to sysad[31:24], and ad[31:24]. 3. be careful if oeb is programmed at reset to have reverse polarity. 4. signals can be optionally buffered for load balancing. connection memory width connect... to... dram address 4 32-bit dadr[11:0] dram address pins dram data (latched) 1,2 32-bit ad[31:0] even latch i/os b side 0 lee oee* oeb 3 even latch i/os a side even bank data pins even latch clkab and clkba even latch leab and leba even latch oeba* even latch oeab dram data (no latch) 1,2 32-bit ad[31:0] even bank data pins
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 72 revision 1.0 11.2.3 64-bit devices notes: 1. system supports decrement. 2. system is litttle endian without decrement. 3. system is big endian without decrement. 4. dev_adr[21:0] is the output of the latch connected to ad[23:2], sampled by ale. 5. be careful if oeb is programmed at reset to have reverse polarity. 6. regardless of endianess, ecas[0]* and ocas[0]* always corresponds to sysad[7:0] and ad[7:0]. ecas[1]* and ocas[1]* always corresponds to sysad[15:8] and ad[15:8]. ecas[2]* and ocas[2]* always corresponds to sysad[23:16] and ad[23:16]. ecas[3]* and ocas[3]* always corresponds to sysad[31:24] and ad[31:24]. connection memory width connect.. . to... device address 1 6 4 - b i t d a d r [ 2 : 0 ] dadr[2:0] even latch outputs odd latch outputs leadre leadro {dev_adr[21:2], badre[2:1]} 4 {dev_adr[21:2}, badro[2:1]} 4 even latch inputs odd latch inputs become burst address even (badre[2:0]) become burst address odd (badro[2:0]) even latch le odd latch le even bank address pins odd bank address pins device address 2 64-bit dadr[2:0] odd latch outputs leadro {dev_adr[21:2], dadr[2:1]} 4 {dev_adr[21:2}, badro[2:1]} 4 odd latch inputs become burst address odd (badro[2:0]) odd latch le even bank address pins odd bank address pins device address 3 64-bit dadr[2:0] even latch outputs leadro {dev_adr[21:2], badre[2:1]} 4 {dev_adr[21:2}, dadr[2:1]} 4 even latch inputs become burst address even (badre[2:0]) even latch le even bank address pins odd bank address pins device data (latched) 6 64-bit ad[31:0] even latch i/os b side 0 lee oee* oeb 5 ad[31:0] odd latch i/os b side 0 leo oeo* oeb 5 even latch i/os a side even bank data pins even latch clkab and clkba even latch leab and leba even latch oeba* even latch oeab odd latch i/os a side odd bank data pins odd latch clkab and clkba odd latch leab and leba odd latch oeba* odd latch oeab device control 64-bit ad[31:0] ale control latch bit[0] output control latch bit[1] output control latch bit[23:2] outputs control latch bit[27:24] outputs control latch bit[31:28] outputs control latch inputs control latch le becomes bootcs* becomes devrw* becomes dev_adr [21:0] becomes dmaack[3:0]* becomes cs[3:0]*
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 11.2.4 32-bit or less devices it is optional to have one bi-directional buffer. notes: 1. example shows even bank choice, but odd bank can be selected instead. 2. dev_adr[21:0] is the output of the latch connected to ad[23:2], sampled by ale 3. bidirectional latch is optional for buffering, and either odd or even bank can be chosen. this example shows an even bank co nnection. 4. regardless of endianess, ewr[0]* always corresponds to sysad[7:0] and ad[7:0] regardless of endianess. ewr[1]* always corresponds to sysad[15:8] and ad[15:8] regardless of endianess. ewr[2]* always corresponds to sysad[23:16] and ad[23:16] regardless of endianess. ewr[3]* always corresponds to sysad[31:24] and ad[31:24] regardless of endianess. 5. be careful if oeb is programmed at reset to have reverse polarity. connection memory width connect... to... device address 2 32-bit 16-bit 8-bit {dev_adr[21:2], dadr[2:0]} {dev_adr[21:0], dadr[2:1]} {dev_adr[21:0], dadr[2:0]} device address pins device address pins device address pins device data (latched) 3,4 32-bit or less ad[31:0] or [15:0] or [7:0] even latch i/os b side 0 lee oee* oeb 5 even latch i/os a side even bank data pins even latch clkab and clkba even latch leab and leba even latch oeba* even latch oeab device data (no latch) 32-bit or less ad[31:0] or [15:0] or [7:0] device data pins device control 32-bit or less ad[31:0] ale control latch bit[0] output control latch bit[1] output control latch bit[23:2] outputs control latch bit[27:24] outputs control latch bit[31:28] outputs control latch inputs control latch le becomes bootcs* becomes devrw* becomes dev_adr [21:0] becomes dmaack[3:0]* becomes cs[3:0]*
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 74 revision 1.0 12. big and little endian 12.1 background there are two bits in the GT-64111 which control byte swapping. one is located in the cpu/local master interface configuration register (0x000) bit 12. the other is in pci internal command register (0xc00) bit 0. both bits are given the same value as sampled at rst* via pullup/pulldown on interrupt* pin. both can be otherwise programmed after reset is de-asserted. as a master rule, if both bits are set to 1, the GT-64111 assumes little-endian data format and no byte swapping is done within the device. the nomenclature for this section is shown in table 25. table 25. nomenclature 12.1.1 bit 12 of the cpu/local master interface configuration register bit 12 of the cpu/local master interface configuration register (0x000) affects the following: ? set to 1 (little-endian mode): no byte swapping within the cpu/local master interface unit on any data transfer ? set to 0 (big-endian mode): byte swapping of data transfers to/from GT-64111 internal registers (including configuration data register, 0xcfc). no byte swapping of data transfers of which the source/target is external. 12.1.2 bit 0 of the pci internal command register bit 0 of the pci internal command register (0xc00) affects the following: ? set to 1 (no byte swapping): no byte swapping within the pci interface unit of any data transfer. ? set to 0 (byte swapping): no byte swapping of data transfers to/from pci interface units internal registers. byte swapping of data transfers of which the source/target is external 12.2 configuring a system for big and little endian table 26 shows alll combinations of the resources and swapping bits with sample data. ? cpu/local master bit = bit 12 of the cpu/local master interface configuration register (0x000). ? pci bit = bit 0 of the pci internal command register (0xc00). name definition w, word 32-bits of data, r4600 terminology. dw, double word 64-bits of data, r4600 terminology. even address address of which a[2] == 0. in little-endian format this address points to the least significant w of a dw. in big-endian format this address points to the most significant w of a dw. odd address address of which a[2] == 1. in little-endian format this address points to the most significant w of a dw. in big-endian format this address points to the least significant w of a dw. even word least significant w of a dw. odd word most significant w of a dw.
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 the sample data is 0x04030201. table 26. configuring for big and little endian swap bits (cpu/local master bit:pci bit) resource 11 00 01 10 internal registers (cpu/local master access) 04030201 01020304 01020304 04030201 internal registers (pci access) 04030201 04030201 04030201 04030201 internal pci configuration registers (cpu/ local master access) 04030201 01020304 01020304 04030201 internal pci configuration registers (pci access) 04030201 04030201 04030201 04030201 external pci configuration registers 04030201 04030201 01020304 01020304 memory (dram and devices) (cpu/local master access) 04030201 04030201 04030201 04030201 memory (dram and devices) (pci access) 04030201 01020304 04030201 01020304 cpu/local master to pci (except external pci configuration registers) 04030201 01020304 04030201 01020304
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 76 revision 1.0 13. using the GT-64111 without the cpu/local master interface table 27 lists the pins that must be strapped when the GT-64111 is used without the cpu/local master interface (i.e. pci memory controller only). please note that rst* and tclk must always be connected. each pin must be strapped with a separate resistor unless otherwise noted. table 27. cpu-less pin strapping 14. using the GT-64111 without the pci interface table 28 lists the pins that must be strapped when the GT-64111 is used with the pci interface. please note that rst* must always be connected. each pin must be strapped with a separate resistor. table 28. pci-less pin strapping 1. galileo recommends using 4.7kohm resistors. 2. sysad[31:0] can be pulled up through a single resistor instead of 32 separate resistors. 3. syscmd[8:0] can be pulled up through a single resistor instead of 9 separate resistors. 1. galileo recommends using 4.7kohm resistors. pin strapping 1 validout* pulled up to vdd through a resistor release* pulled up to vdd through a resistor sysad[31:0] 2 pulled up to vdd through a resistor syscmd[8:0] 3 pulled up to vdd through a resistor validin* no connect wrrdy* no connect interrupt* sampled at rst*, see reset section. pin strapping 1 pclk pulled up to vdd through a resistor devsel* pulled up to vdd through a resistor stop* pulled up to vdd through a resistor par no connect perr* pulled up to vdd through a resistor frame* pulled up to vdd through a resistor irdy* pulled up to vdd through a resistor trdy* pulled up to vdd through a resistor gnt* pulled down to gnd through a resistor idsel* pulled down to gnd through a resistor serr* no connect req* no connect int* no connect ad[31:0] no connect cbe*[3:0] no connect
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 15. applications: system configurations 15.1 minimal system configuration a minimal system configuration is shown below. it includes an 8-bit wide boot rom, a 32-bit wide dram, and a pci interface to industry standard i/o devices. this configuration can be appealing to applications that need high perfor- mance and are limited to a minimal board space. gt- 64111 dram boot rom 8 32 pci cs* dadr[11:0] ecas*[3:0] ras*[0] dwr* ad[31:0] pci i/o pci i/o ale latch or cstiming* sysad bootcs* dev_adr [21:0] dadr[2:0] 32 32 32 mips cpu
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 78 revision 1.0 15.2 typical system the high performance system shown below includes 64-bit wide memories and 32-bit i/o devices on the pci bus. the system includes flash for storing code and data, and dram as main memory. in this system data can be moved via dma or pci master accesses between the pci bus and the flash or dram at full bus bandwidth, at 200 mbytes per second. the cpu/local master can read from the dram at peak bandwidth of 264mbytes per second. cpu/local master writes have peak bandwidth of 264mbytes per second for all devices through the GT-64111 on-chip write buffer. pci slave pci master dram flash 373 373 501 pci ad[31:0] GT-64111 sysad[31:0] or dadr[11:0] leadre ecas[3:0]* ed[31:0] od[31:0] dadr[2:0] dev_adr[21:2] ad[31:0] ale cstiming* lee, oee*, oeb d[31:0] bootcs* cs* 32 32 32 32 501 32 leo, oeo*, oeb dadr[11:0] 373 leadr0 dram ocas[3:0]* ras* ras* mips cpu
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 15.3 interface to asynchronous devices in this case, we show the connectivity between the GT-64111 and 64 bit-wide standard memory devices (e.g. sram). in this example the latches selected are industry standard fct16501 for data, fct16373 for the address, and fct16373 for the burst address for the odd bank. the data latches that interface to the ad bus are used to interleave the data in read and write access from the GT-64111 and enable data rate of one data per cycle at 66mhz (200 mbytes per second peak rate). fct16373 logic chips are used to latch the address, the cs* and the devrw*for the devices. the latch for the odd bank burst address is needed for the address interleaving. this system configuration is for little endian, no decrement. lee oee* ale leo oeo* cs[0]* cs[0]* ad[31:0] oeb oeb ewr[3:0]* owr[3:0]* dadr[2:1] badr[2:1] devoe* flash eprom sram rom flash eprom sram 373 odd bank even bank rom 373 leadro gt- devoe* or cstiming* devrw* 64111 dev_adr[21:0] dadr[2:0] dev_adr[21:0] oeab leab leba oeba * 501 b a oeab leab leba oeba * 501 b a 32 32 or 32 32 mips cpu
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 80 revision 1.0 15.4 interface to dram the dram and the device interface in a typical system share the same data latches and address latches. in this exam- ple the dram is 64 -bit wide and the even and odd banks share the same ras[0]* pin. address for the odd bank is driven from an fct16373 latch which is controlled by leadro. the data latches used in this example are fct16501 to the ad bus. this system configuration is for little endian, no decrement. leadro ecas[3:0]* ocas[3:0]* dwr* dwr* dadr[11:0] ras[0]* ras[0]* odd bank even bank lee oee* leo oeo* oeb oeb 373 ad[31:0] gt- dram dram 64111 oeab leab leba oeba * 501 b a oeab leab leba oeba * 501 b a 32 32 32 32 mips cpu
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 15.5 a system with parity in this case, the fct16511 is used to generate parity for all the write accesses to the devices and the dram. in a cpu/ local master read access the fct16511 will check parity and will assert the parerr* signal when an error is detected. the GT-64111 will indicate to the cpu/local master that the returned data is erroneous via syscmd[5] and will inter- rupt the cpu/local master if the bank that the cpu/local master read from was programmed to have parity integrity checks. the GT-64111 also asserts syscmd[4] to indicate to the cpu/local master if the read access was from an address with parity integrity so that the cpu/local master will check parity internally as well. in pci read accesses, an active parerr* to a bank that has parity integrity, will cause an assertion of perr* on the pci. notice that with the fct16511 the oeab* polarity is active low, as opposed to the fct16501, and thus oeb from the GT-64111 should be programmed accordingly at reset. this system configuration is for little endian, no decrement. leadro ecas[3:0]* ocas[3:0]* dwr* dwr* dadr[11:0] ras[0]* ras[0]* odd bank even bank lee oee* leo oeo* oeb oeb oeab* leab leba oeba * b a 841 ad[31:0] gt- 511 parerr* pera* 32 32 36 36 32 64111 dram dram oeab* leab leba oeba * b a 511 pera* 36 mips cpu
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 82 revision 1.0
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 16. designing for compatibility with the gt-64011 the GT-64111 is nearly drop-in compatible with the gt-64011 device. with careful hardware and software design it is possible to design a system that can accept both devices. this section highlights the differences between the two chips, and explains how to design to handle these differences. 16.1 major hardware differences between the gt-64011 and GT-64111 the only major differences between the two devices are: ? the GT-64111 requires a vcc of 3.3v; the gt-64011 is a 5v part. you will need to design your board to deliver the proper voltage to the supply plane depending on which device is installed. zero-ohm resistors are a good way to do this. ? the vref pin on the gt-64011 is replaced by vio on the GT-64111. the gt-64011 used vref to set the cpu interface voltage to either 3.3v or 5v depending on the voltage sampled on the pin. the GT-64111 uses this pin to set the pci voltage to either 3.3v or 5v; the cpu interface voltage is always 3.3v on the GT-64111. your system may need a jumper or zero-ohm resistor to account for this change. ? pin 15 is a vss on the gt-64011; it is 66mhz pci comaptible enable on the GT-64111. if your system does not need the 66mhz compatibility bit set then tie this to vss directly. if you need to be able to upgrade from a gt-64011 and want to be able to advertise (in configration space) 66mhz capability, then tie this pin to a jumper that can be vss or vcc. in any case, the pci bus will still run at 66mhz. 16.2 all differences between the gt-64011 and GT-64111 table 29, below, outlines all differences between the gt-64011 and GT-64111 and include comments on their potential system implications. table 29. differences between the gt-64011 and GT-64111 function gt-64011 GT-64111 comment on compatibility vcc 5v 3.3v board must have the capability of supplying either 5v or 3.3v to vcc. pin 80 vref vio you may need a jumper to connect this pin to vref for gt-64011 designs; vio for gt- 64111 designs. pin 15 vss 66mhz capabil- ity enable you may need a jumper to enable the advertisement of 66mhz capability in the pci header (see above). this pin does not affect the actual speed of the pci interface. pci bus frequency 33mhz 66mhz no issues other than the 66mhz capability bit. 4300 bus mode sup- port none yes validout* pulled-up to vdd through a 4.7kohm resistor. linear burst address support none enabled through bit 9 of register 0x454 there should be no issues as long as your software does not set reserved bit in regis- ters (especially 0x454). default class code 0x0600 0x0580 there may be issues with drivers written for class code 0x0600. the class code in the GT-64111 can be overwritten by software if this is the case. revid 0x01 0x10 there should be no issues as long as your software/drivers account for the fact that revids change with silicon stepping.
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 84 revision 1.0 base address enable register reset state enabled most disabled your software may need to manually enable the less often used bars that are now disabled by default. (this change was made for pc add-in cards without boot roms.) prefetch bit in mem- ory bars read/write hardwired to 1 no issues. errata fixes all known errata corrected. please check your gt-64011 for workarounds that may no longer be neces- sary. function gt-64011 GT-64111 comment on compatibility
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 17. register tables the GT-64111s internal registers can be accessed by the cpu/local master or from the pci bus. they are memory- mapped for the cpu/local master and memory- or i/o-mapped for the pci. the registers address is comprised of the value in the internal space decode register and the register offset. the value in the internal space decode register [10:0] is matched against bits [31:21] of the actual address; therefore, this value should be the actual address bits [31:21] shifted right once. for example, to access channel 0 dma byte count register (offset 0x800) immediately after reset*, the full address will be the default value in the internal space decode register which is 0x0a0 shifted left once, which gives 0x140, two zeros and the offset 0x800, to become a 32-bit address of 0x14000800. the location of the registers in the mem- ory space can be changed by changing the value programmed into the internal space decode register. for example after changing the value in the internal space decode register by writing to 0x14000068 a value of 0bd, an access to the channel 0 dma byte count register will be with 0x17a00800. detailed information about setting the registers is contained in their respective sections of this data sheet. 17.1 access to on-chip pci configuration space registers an access to a pci configuration register is performed differently than accesses to all other registers. the access is performed indirectly by writing the pci configuration register offset into the configuration address register and then reading or writing the data from/to the configuration data register. for example, to read data from the status and command register, the register offset 0x004 is written into the config- uration address register, offset 0xcf8 (or full address from the previous example 0xbd000cf8). then, reading from the configuration data register (offset 0xcfc), will return the data of the status and command register. 17.2 register map description offset cpu/local master interface cpu/local master interface configuration 0x000 processor address space ras[1:0] low decode address 0x008 ras[1:0] high decode address 0x010 ras[3:2] low decode address 0x018 ras[3:2] high decode address 0x020 cs[2:0] low decode address 0x028 cs[2:0] high decode address 0x030 cs[3] & boot cs low decode address 0x038 cs[3] & boot cs high decode address 0x040 pci i/o low decode address 0x048 pci i/o high decode address 0x050 pci memory 0 low decode address 0x058 pci memory 0 high decode address 0x060 internal space decode 0x068
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 86 revision 1.0 bus error address low processor 0x070 read only 0 0x078 pci memory 1 low decode address 0x080 pci memory 1 high decode address 0x088 dram and device address space ras[0] low decode address 0x400 ras[0] high decode address 0x404 ras[1] low decode address 0x408 ras[1] high decode address 0x40c ras[2] low decode address 0x410 ras[2] high decode address 0x414 ras[3] low decode address 0x418 ras[3] high decode address 0x41c cs[0] low decode address 0x420 cs[0] high decode address 0x424 cs[1] low decode address 0x428 cs[1] high decode address 0x42c cs[2] low decode address 0x430 cs[2] high decode address 0x434 cs[3] low decode address 0x438 cs[3] high decode address 0x43c boot cs low decode address 0x440 boot cs high decode address 0x444 address decode error 0x470 dram configuration dram configuration 0x448 dram parameters dram bank0 parameters 0x44c dram bank1 parameters 0x450 dram bank2 parameters 0x454 dram bank3 parameters 0x458 device parameters
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 device bank0 parameters 0x45c device bank1 parameters 0x460 device bank2 parameters 0x464 device bank3 parameters 0x468 device boot bank parameters 0x46c dma record channel 0 dma byte count 0x800 channel 1 dma byte count 0x804 channel 2 dma byte count 0x808 channel 3 dma byte count 0x80c channel 0 dma source address 0x810 channel 1 dma source address 0x814 channel 2 dma source address 0x818 channel 3 dma source address 0x81c channel 0 dma destination address 0x820 channel 1 dma destination address 0x824 channel 2 dma destination address 0x828 channel 3 dma destination address 0x82c channel 0 next record pointer 0x830 channel 1 next record pointer 0x834 channel 2 next record pointer 0x838 channel 3 next record pointer 0x83c dma channel control channel 0 control 0x840 channel 1 control 0x844 channel 2 control 0x848 channel 3 control 0x84c dma arbiter arbiter control 0x860 timer/counter timer /counter 0 0x850 timer /counter 1 0x854 timer /counter 2 0x858
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 88 revision 1.0 timer /counter 3 0x85c timer /counter control 0x864 pci internal command 0xc00 time out & retry 0xc04 ras[1:0] bank size 0xc08 ras[3:2] bank size 0xc0c cs[2:0] bank size 0xc10 cs[3] & boot cs bank size 0xc14 serr mask 0xc28 interrupt acknowledge 0xc34 base address registers enable 0xc3c configuration address 0xcf8 configuration data 0xcfc interrupts interrupt cause 0xc18 cpu/local master mask 0xc1c pci mask 0xc24 pci configuration device and vendor id 0x000 status and command 0x004 class code and revision id 0x008 bist, header type, latency timer, cache line 0x00c ras[1:0] base address 0x010 ras[3:2] base address 0x014 subsystem device and vendor id 0x02c cs[2:0] base address 0x018 cs[3] & boot cs base address 0x01c internal registers memory mapped base address 0x020 internal registers i/o mapped base address 0x024 expansion rom base address register 0x030 interrupt pin and line 0x03c pci configuration, function 1
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 ras[1:0] swapped base address 0x010 cas[3:2] swapped base address 0x014 cs[3] and boot cs swapped base address and expansion rom base 0x01c
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 90 revision 1.0 17.3 cpu/local master interface cpu/local master interface configuration, offset: 0x000 17.4 cpu/local master decode ras[1:0] low decode address, offset: 0x008 ras[1:0] high decode address, offset: 0x010 ras[3:2] low decode address, offset: 0x018 ras[3:2] high decode address, offset: 0x020 bits field name function initial value 10:0 reserved read only 0. 0x0 11 writemode write mode. 0 - pipelined writes mode 1 - r4000 mode (2 dead-cycles minimum between consecutive address-phases) 0x0 12 endianess byte orientation. 0 - big endian 1 - little endian sampled at rst* via the interrupt* pin 31:13 reserved 0x0 bits field name function initial value 10:0 low dram banks 1 and 0 will be accessed when the decoded addresses are between low and high. 0x000 31:11 reserved 0x0 bits field name function initial value 6:0 high dram banks 1 and 0 will be accessed when the decoded addresses are between low and high. 0x07 31:7 reserved 0x0 bits field name function initial value 10:0 low dram banks 3 and 2 will be accessed when the decoded addresses are between low and high. 0x008 31:11 reserved 0x0 bits field name function initial value 6:0 high dram banks 3 and 2 will be accessed when the decoded addresses are between low and high. 0x0f 31:7 reserved 0x0
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 cs[2:0] low decode address, offset: 0x028 cs[2:0] high decode address, offset: 0x030 cs[3] & boot cs low decode address, offset: 0x038 cs[3] & boot cs high decode address, offset: 0x040 pci i/o low decode address, offset: 0x048 pci i/o high decode address, offset: 0x050 bits field name function initial value 10:0 low device banks 2, 1 and 0 will be accessed when the decoded addresses are between low and high. 0x0e0 31:11 reserved 0x0 bits field name function initial value 6:0 high device banks 2, 1 and 0 will be accessed when the decoded addresses are between low and high. 0x70 31:7 reserved 0x0 bits field name function initial value 10:0 low device bank 3 and the boot bank will be accessed when the decoded addresses are between low and high. 0x0f8 31:11 reserved 0x0 bits field name function initial value 6:0 high device bank 3 and the boot bank will be accessed when the decoded addresses are between low and high. 0x7f 31:7 reserved 0x0 bits field name function initial value 10:0 low the pci i/o address space will be accessed when the decoded addresses are between low and high. 0x080 31:11 reserved 0x0 bits field name function initial value 6:0 high the pci i/o address space will be accessed when the decoded addresses are between low and high. 0x0f 31:7 reserved 0x0
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 92 revision 1.0 pci memory 0 low decode address, offset: 0x058 pci memory 0 high decode address, offset: 0x060 internal space decode, offset: 0x068 bus error address processor, offset: 0x070 reserved, offset: 0x078 pci memory 1 low decode address, offset: 0x080 bits field name function initial value 10:0 low the pci memory 0 address space will be accessed when the decoded addresses are between low and high. 0x090 31:11 reserved 0x0 bits field name function initial value 6:0 high the pci memory 0 address space will be accessed when the decoded addresses are between low and high. 0x1f 31:7 reserved 0x0 bits field name function initial value 10:0 intdecode registers inside the GT-64111 will be accessed when masad bits 31:21 match the value programmed in bits 10:0. 0x0a0 31:11 reserved 0x0 bits field name function initial value 31:0 ilegloadd this register captures bits 31:0 of an illegal 32-bit address. 0x00000000 bits field name function initial value 31:0 reserved read only 0. 0x0 bits field name function initial value 10:0 low the pci memory address space will be accessed when the decoded addresses are between low and high. 0x790 31:11 reserved 0x0
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 pci memory 1 high decode address, offset: 0x088 17.5 device decode ras[0] low decode address, offset: 0x400 ras[0] high decode address, offset: 0x404 ras[1] low decode address, offset: 0x408 ras[1] high decode address, offset: 0x40c ras[2] low decode address, offset: 0x410 bits field name function initial value 6:0 high the pci memory address space will be accessed when the decoded addresses are between low and high. 0x1f 31:7 reserved 0x0 bits field name function initial value 7:0 low dram bank 0 will be accessed when the decoded addresses are between low and high. 0x00 31:8 reserved 0x0 bits field name function initial value 7:0 high dram bank 0 will be accessed when the decoded addresses are between low and high. 0x07 31:8 reserved 0x0 bits field name function initial value 7:0 low dram bank 1 will be accessed when the decoded addresses are between low and high. 0x08 31:8 reserved 0x0 bits field name function initial value 7:0 high dram bank 1 will be accessed when the decoded addresses are between low and high. 0x0f 31:8 reserved 0x0 bits field name function initial value 7:0 low dram bank 2 will be accessed when the decoded addresses are between low and high. 0x10 31:8 reserved 0x0
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 94 revision 1.0 ras[2] high decode address, offset: 0x414 ras[3] low decode address, offset: 0x418 ras[3] high decode address, offset: 0x41c cs[0] low decode address, offset: 0x420 cs[0] high decode address, offset: 0x424 cs[1] low decode address, offset: 0x428 bits field name function initial value 7:0 high dram bank 2 will be accessed when the decoded addresses are between low and high. 0x17 31:8 reserved 0x0 bits field name function initial value 7:0 low dram bank 3 will be accessed when the decoded addresses are between low and high. 0x18 31:8 reserved 0x0 bits field name function initial value 7:0 high dram bank 3 will be accessed when the decoded addresses are between low and high. 0x1f 31:8 reserved 0x0 bits field name function initial value 7:0 low device bank 0 will be accessed when the decoded addresses are between low and high. 0xc0 31:8 reserved 0x0 bits field name function initial value 7:0 high device bank 0 will be accessed when the decoded addresses are between low and high. 0xc7 31:8 reserved 0x0 bits field name function initial value 7:0 low device bank 1 will be accessed when the decoded addresses are between low and high. 0xc8 31:8 reserved 0x0
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 cs[1] high decode address, offset: 0x42c cs[2] low decode address, offset: 0x430 cs[2] high decode address, offset: 0x434 cs[3] low decode address, offset: 0x438 cs[3] high decode address, offset: 0x43c boot cs low decode address, offset: 0x440 bits field name function initial value 7:0 high device bank 1 will be accessed when the decoded addresses are between low and high. 0xcf 31:8 reserved 0x0 bits field name function initial value 7:0 low device bank 2 will be accessed when the decoded addresses are between low and high. 0xd0 31:8 reserved 0x0 bits field name function initial value 7:0 high device bank 2 will be accessed when the decoded addresses are between low and high. 0xdf 31:8 reserved 0x0 bits field name function initial value 7:0 low device bank 3 will be accessed when the decoded addresses are between low and high. 0xf0 31:8 reserved 0x0 bits field name function initial value 7:0 high device bank 3 will be accessed when the decoded addresses are between low and high. 0xfb 31:8 reserved 0x0 bits field name function initial value 7:0 low boot bank will be accessed when the decoded addresses are between low and high. 0xfc 31:8 reserved 0x0
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 96 revision 1.0 boot cs high decode address, offset: 0x444 address decode error, offset: 0x470 17.6 dram configuration dram configuration, offset: 0x448 17.7 dram parameters dram bank0 parameters, offset: 0x44c bits field name function initial value 7:0 high boot bank will be accessed when the decoded addresses are between low and high. 0xff 31:8 reserved 0x0 bits field name function initial value 31:0 erraddr the addresses of accesses to invalid address ranges (those not in the range programmed in the dram or device decode registers) will be captured in this regis- ter. undefined value bits field name function initial value 13:0 refintcnt refresh interval count value. 0x0200 15:14 reserved when written, this bits can be safely programmed to any value. when read, these bits will respond with an undefined value. n/a 16 stagref staggered refresh. 0 - staggered refresh 1- all banks are refreshed together 0x0 17 adsfunct defines the function of the dadr[11]/ads* pin. 0 - dadr11 only 1 - ads* only 0x0 18 dramlatch sets the latch operation mode. 0 -the latch control signals are active. 1 - the external data latches are transparent in dram accesses when cas is programmed to be one cycle long 0x0 31:19 reserved when written, these bits can be safely programmed to any value. when read, these bits will respond with an undefined value. n/a bits field name function initial value 0 caswr the number of cycles cas* is low in a write access. 0 - one cycle 1 - two cycles 0x1 1 rastocaswr the number of cycles between ras* going active and cas* going active in a write access. 0 - two cycles 1 - three cycles 0x1
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 dram bank1 parameters, offset: 0x450 dram bank2 parameters, offset: 0x454 dram bank3 parameters, offset: 0x458 2 casrd the number of cycles cas* is low in a read access. 0 - one cycle 1 - two cycles 0x1 3 rastocasrd the number of cycles between ras* going active and cas* going active in a read access. 0 - two cycles 1 - three cycles 0x1 5:4 refresh dram type support. 00 - 1/2k refresh (9 bits row, 9 to 12 bits column) 01 - 1k refresh (10 bits row, 9 to 12 bits column) 10 - 2k refresh (11 bits row, 9 to 12 bits column) 11 - 4k refresh (12 bits row, 9 to 12 bits column) 0x0 6 bankwidth width of dram bank. 0- 32 (36) bit wide dram 1- 64 (72) bit wide interleaved dram 0x0 7 bankloc location of a 32-bit wide bank. 0- even 1- odd 0x0 8 parity parity support for the bank. 0- no parity support 1- parity supported 0x0 9 reserved must be programmed 0. 0x0 31:10 reserved when written, these bits can be safely programmed to any value. when read, these bits will respond with an undefined value. n/a bits field name function initial value 31:0 various fields function as in dram bank0. 0xf bits field name function initial value 0:8 various fields function as in dram bank0. 0xf 9 linearburst sub-block order or linear burst order dram select. 0 - sub-block order 1 - linear burst order 0x0 31:10 various fields function as in dram bank0. 0x0 bits field name function initial value 31:0 various fields function as in dram bank0. 0xf bits field name function initial value
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 98 revision 1.0 17.8 device parameters device bank0 parameters, offset: 0x45c bits field name function initial value 2:0 turnoff the number of cycles between the deassertion of devoe* (an externally extracted signal which is the logical or between cstiming* and inverted devrw*) to a new ad bus cycle. 0x7 6:3 acctofirst the number of cycles in a read access from the assertion of cs* to the cycle that the data will be latched (by the external latches). can be extended via the ready* pin. 0xf 10:7 acctonext the number of cycles in a read access from the cycle that the first data was latched to the cycle that the next data will be latched (in burst accesses). can be extended via the ready* pin. 0xf 13:11 adstowr the number of cycles from ads* active to the asser- tion of ewr* or owr*. 0x7 16:14 wractive the number of cycles ewr* or owr* are active. can be extended via the ready* pin. 0x7 19:17 wrhigh the number of cycles between deassertion and assertion of ewr* or owr*. 0x7 21:20 devwidth device width. 00 - 8 bits 01 - 16 bits 10 - 32 bits 11 - 64 bits 0x2 22 reserved must be programmed 1. 0x1 23 devloc 32-bit, 16-bit, or 8-bit device location. 0 - even bank 1 - odd bank 0x0 24 reserved read only. 0x0 25 latchfunct latch function in read cycles. 0 - always transparent 1 - latch enable signals are active. 0x0 27:26 reserved read only. 0x1 29:28 reserved read only. 0x1 30 parity parity support for the bank. 0- no parity support 1- parity supported 0x0 31 reserved when written, this bit can be safely programmed to any value. when read, this bit will respond with an undefined value. n/a
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 device bank1 parameters, offset: 0x460 device bank2 parameters, offset: 0x464 device bank3 parameters, offset: 0x468 device boot bank parameters, offset: 0x46c in case of the cs[3]* or boot bank, bits 23:20 are shown as ? because bits 21:20 are sampled at reset via dadr[11:10] to define the width of the device. 17.9 dma record channel 0 dma byte count, offset: 0x800 channel 1 dma byte count, offset: 0x804 channel 2 dma byte count, offset: 0x808 bits field name function initial value 31:0 various fields function as in device bank0. 0x146fffff bits field name function initial value 31:0 various fields function as in device bank0. 0x146fffff bits field name function initial value 31:0 various fields function as in device bank0. 0x14?fffff bits field name function initial value 31:0 various fields function as in device bank0. 0x14?fffff bits field name function initial value 15:0 bytect the number of bytes that are left in dma transfers. 0x0 31:16 reserved 0x0 bits field name function initial value 15:0 bytect the number of bytes that are left in dma transfers. 0x0 31:16 reserved 0x0 bits field name function initial value 15:0 bytect the number of bytes that are left in dma transfers. 0x0 31:16 reserved 0x0
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 100 revision 1.0 channel 3 dma byte count, offset: 0x80c channel 0 dma source address, offset: 0x810 channel 1 dma source address, offset: 0x814 channel 2 dma source address, offset: 0x818 channel 3 dma source address, offset: 0x81c channel 0 dma destination address, offset: 0x820 channel 1 dma destination address, offset: 0x824 bits field name function initial value 15:0 bytect the number of bytes that are left in dma transfers. 0x0 31:16 reserved 0x0 bits field name function initial value 31:0 srcadd the address that the dma controller will read the data from. 0x0 bits field name function initial value 31:0 srcadd the address that the dma controller will read the data from. 0x0 bits field name function initial value 31:0 srcadd the address that the dma controller will read the data from. 0x0 bits field name function initial value 31:0 srcadd the address that the dma controller will read the data from. 0x0 bits field name function initial value 31:0 destadd the address that the dma controller will write the data to. 0x0 bits field name function initial value 31:0 destadd the address that the dma controller will write the data to. 0x0
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 channel 2 dma destination address, offset: 0x828 channel 3 dma destination address, offset: 0x82c channel 0 next record pointer, offset: 0x830 channel 1 next record pointer, offset: 0x834 channel 2 next record pointer, offset: 0x838 channel 3 next record pointer, offset: 0x83c bits field name function initial value 31:0 destadd the address that the dma controller will write the data to. 0x0 bits field name function initial value 31:0 destadd the address that the dma controller will write the data to. 0x0 bits field name function initial value 31:0 nextrecptr the address for the next record of dma. a value of 0 means a null pointer (end of the chained list). 0x0 bits field name function initial value 31:0 nextrecptr the address for the next record of dma. a value of 0 means a null pointer (end of the chained list). 0x0 bits field name function initial value 31:0 nextrecptr the address for the next record of dma. a value of 0 means a null pointer (end of the chained list). 0x0 bits field name function initial value 31:0 nextrecptr the address for the next record of dma. a value of 0 means a null pointer (end of the chained list). 0x0
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 102 revision 1.0 17.10 dma channel control channel 0 control, offset: 0x840 bits field name function initial value 1:0 addcontrol sets the locations of the source/destination of the dma access (64011/14/60 rev p-1 and later only): 00 - source and destination are in the local address space. 01 - source is in pci memory space and destination in the local address space. 10 - destination is in pci memory space and source in the local address space. 11 - source and destination are in pci memory space. these bits are reserved (must be = 00) in the gt- 64011-p-0 and gt-64010a. 0x0 3:2 srcdir source direction. 00 - increment source address 01 - decrement source address 10 - hold in the same value 0x0 5:4 destdir destination direction. 00 - increment destination address 01 - decrement destination address 10 - hold in the same value 0x0 8:6 datatranslim data transfer limit in each dma access. 101 - 1 byte 110 - 2 bytes 000 - 4 bytes 001 - 8 bytes 011 - 16 bytes 111 - 32 bytes 0x0 9 chainmod chained mode. 0 - chained mode; when a dma access is terminated, the parameters of the next dma access will come from a record in memory that a nextrecptr register points at. 1 - non-chained mode; only the values that are pro- grammed by the cpu/local master (or pci) directly into the bytect, srcadd, and destadd registers are used. 0x0 10 intmode interrupt mode. 0 - interrupt asserted every time the dma byte count reaches terminal count. 1 - interrupt every null pointer (in chained mode) 0x0 11 transmod transfer mode. 0 - demand 1 - block 0x0 12 chanen channel enable. 0 - disable 1 - enable 0x0
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 channel 1 control, offset: 0x844 channel 2 control, offset: 0x848 channel 3 control, offset: 0x84c 13 fetnexrec fetch next record. 1 - forces a fetch of the next record (even if the cur- rent dma has not ended). this bit is reset after fetch is completed (meaningful only in chained mode). 0x0 14 dmaactst dma activity status (read only). 0 - channel is not active 1 - channel is active 0x0 31:15 reserved 0x0 bits field name function initial value 31:0 various fields function as in channel 0 control. 0x0 bits field name function initial value 31:0 various fields function as in channel 0 control. 0x0 bits field name function initial value 31:0 various fields function as in channel 0 control. 0x0 bits field name function initial value
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 104 revision 1.0 17.11 arbiter control, offset: 0x860 17.12 timer / counter timer/counter 0, offset: 0x850 timer/counter 1, offset: 0x854 timer/counter 2, offset: 0x858 bits field name function initial value 1:0 priochan1/0 priority between channel 0 and channel 1. 00 - round robin 01 - priority to channel 1 over channel 0 10 - priority to channel 0 over channel 1 11 - reserved 0x0 3:2 priochan3/2 priority between channel 2 and channel 3. 00 - round robin 01 - priority to channel 3 over 2 10 - priority to channel 2 over 3 11 - reserved 0x0 5:4 priogrps priority between the group of channels 0/1 and the group of channels 2/3. 00 - round robin 01 - priority to channels 2/3 over 0/1 10 - priority to channels 0/1 over 2/3 11 - reserved 0x0 6 prioopt defines the arbiter behavior for high priority device. 0 - high priority device will relinquish the bus for a requesting device for one dma transaction after it was serviced. 1 - high priority device will be granted as long as it requests the bus. 0x0 31:7 reserved 0x0 bits field name function initial value 31:0 tc0value the counter or timer initial value. 0x0 bits field name function initial value 23:0 tc1value the counter or timer initial value. 0x0 31:24 reserved 0x0 bits field name function initial value 23:0 tc2value the counter or timer initial value. 0x0 31:24 reserved 0x0
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 timer/counter 3, offset: 0x85c timer/counter control, offset: 0x864 bits field name function initial value 23:0 tc3value the counter or timer initial value. 0x0 31:24 reserved 0x0 bits field name function initial value 0 entc0 the timer/counter will count only when it is enabled. 0 - disable 1 - enable 0x0 1 seltc0 timer or counter selection. 0 - counter 1 - timer 0x0 2 entc1 the timer/counter will count only when it is enabled. 0 - disable 1 - enable 0x0 3 seltc1 timer or counter selection. 0 - counter 1 - timer 0x0 4 entc2 the timer/counter will count only when it is enabled. 0 - disable 1 - enable 0x0 5 seltc2 timer or counter selection . 0 - counter 1 - timer 0x0 6 entc3 the timer/counter will count only when it is enabled. 0 - disable 1 - enable 0x0 7 seltc3 timer or counter selection. 0 - counter 1 - timer 0x0 31:8 reserved 0x0
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 106 revision 1.0 17.13 pci internal command, offset: 0xc00 time out & retry, offset: 0xc04 1. regardless of the selected sync mode, pclk frequency must be smaller than tclk frequency by at least 1mhz bits field name function initial value 0 byteswap when set to zero, the GT-64111 swaps the incoming and outgoing pci data. if there is a pci address hit in an enabled swap bar, the data will be transferred opposite as it would according to the setting of byteswap. set to the same value sampled at reset into bit[12] of the cpu/ local master interface configuration register. 2:1 syncmode 1 indicates the ratio between tclk and pclk as follows: 00 - when the pclk ranges from dc to 66mhz (default mode; use following settings for higher perfor- mance) 01 - when pclk frequency is higher than or equal to half the tclk frequency (e.g. when tclk is 66mhz, syncmode can be set to 01 if the pci frequency is higher than or equal to 33mhz). 1x - when the two clocks are synchronized (derived from the same clock) and pclk frequency is higher than or equal to half the tclk frequency(e.g. tclk = 66mhz, pclk = 33mhz) 0x0 31:3 reserved 0x0 bits field name function initial value 7:0 timeout0 specifies in pci clock units the number of clocks the GT-64111, as a slave, holds the pci bus before the generation of retry termination. used for the first data transfer. 0x0f 15:8 timeout1 specifies in pci clock units the number of clocks the GT-64111, as a slave, holds the pci bus before the generation of disconnect termination. used for data transfers following the first data.the number of pci clock cycles between the last trdy* rise and the stop* falling are n+1, where n is the timeout1 value. 0x07 23:16 retryctr specifies the number of retries of the GT-64111 mas- ter. the GT-64111 generates an interrupt when this timer expires. a value of 0x00 means retry forever. the number in retryctr does not include the first access of the transaction. 0x00 31:24 reserved 0x0
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 ras[1:0] bank size, offset: 0xc08 ras[3:2] bank size, offset: 0xc0c cs[2:0] bank size, offset: 0xc10 cs[3] and boot cs bank size, offset: 0xc14 bits field name function initial value 31:12 banksize specifies the ras[1:0] address mapping in conjunc- tion with the ras[1:0] base address register. set to 0 indicates that the corresponding bit in the address and in the base address must be equal in order to have a hit. set to 1 indicates that the corre- sponding bit in the address is a dont-care. for example, bit 12 set to 1 indicates that the ras[1:0] size is 8kbytes (address bits [12:0] are changeable/dont-care). the set bits in the bank size must be sequential (e.g. 000...001, 000...011, 000...111 are correct values, whereas 000...010 and 000...100 are not). 0x00fff 11:0 reserved 0x0 bits field name function initial value 31:12 banksize specifies the ras[3:2] address mapping in conjunc- tion with the ras[3:2] base address register. same description and setting restrictions as outlined for ras[1:0] bank size, offset: 0xc08. 0x00fff 11:0 reserved 0x0 bits field name function initial value 31:12 banksize specifies the cs[2:0] address mapping in conjunction with the cs[2:0] base address register. same description and setting restrictions as outlined for ras[1:0] bank size, offset: 0xc08. 0x01fff 11:0 reserved 0x0 bits field name function initial value 31:12 banksize specifies the cs[3] and boot cs address mapping in conjunction with the cs[3] and boot cs base address register. same description and setting restrictions as outlined for ras[1:0] bank size, offset: 0xc08. 0x00fff 11:0 reserved 0x0
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 108 revision 1.0 serr mask, offset: 0xc28 interrupt acknowledge, offset: 0xc34 base address registers enable, offset: 0xc3c bits field name function initial value 0 addrerr mask bit. when set, serr* is asserted when the gt- 64111 detects a parity error on the address lines. 0x0 1 maswrerr mask bit. when set, serr* is asserted when the gt- 64111 detects a parity error during a master write operation. 0x0 2 masrderr mask bit. when set, serr* is asserted when the gt- 64111 detects a parity error during a master read operation. 0x0 3 memerr mask bit. when set, serr* is asserted when a memory parity error has been detected (applicable only when an external parity checking device is used). 0x0 4 masabort mask bit. when set, serr* is asserted when the gt- 64111 performs master abort. 0x0 5 tarabort mask bit. when set, serr* is asserted when the gt- 64111 detects a target abort. 0x0 31:6 reserved 0x0 bits field name function initial value 31:0 intack the data is meaningless. a cpu/local master read operation to this register causes the GT-64111 to per- form an interrupt acknowledge cycle on the pci bus. 0x00000000 bits field name function initial value 31:9 reserved 0x0 8 ras[1:0]en controls address matching with ras[1:0] base/size. 0 - enable 1 - disable 0x0 7 ras[3:2]en controls address matching with ras[3:2] base/size. 0 - enable 1 - disable sampled at reset via dmareq[0]*/ready* 6 cs[2:0]en controls address matching with cs[2:0] base/size. 0 - enable 1 - disable sampled at reset via dadr[6] 5 cs[3] & boot csen controls address matching with cs[3] & boot cs base/size. 0 - enable 1 - disable sampled at reset via dadr[3] 4 intmemen controls address matching with internal registers- memory mapped base/size. 0 - enable 1 - disable 0x0
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 the GT-64111 prevents disabling both memory mapped base/size address matching and i/o mapped base/size address matching at the same time (bits 3 and 4 cannot simultaneously be set to 1). configuration address, offset: 0xcf8 configuration data, offset: 0xcfc 3 intioen controls address matching with internal registers i/o mapped base/size. 0 - enable 1 - disable 0x1 2 swras[1:0]en controls address matching with swapped ras[1:0] base/size. 0 - enable 1 - disable 0x1 1 swras[3:2]en controls address matching with swapped ras[3:2] base/size. 0 - enable 1 - disable 0x1 0 swcs[3] & boot csen controls address matching with swapped cs[3] & boot cs base/size. 0 - enable 1 - disable 0x1 bits field name function initial value 7:2 regnum indicates the register number. 0x00 10:8 functnum indicates the function type. 0x0 15:11 devnum indicates the device number. 0x00 23:16 busnum indicates the bus number. 0x00 31 configen when set, an access to the configuration data regis- ter is translated into a configuration or special cycle on the pci bus. 0x0 bits field name function initial value 31:0 config the data is transferred to/from the pci bus when the cpu/local master accesses this register and the configen bit in the configuration address register is set. a cpu/local master access to this register causes the GT-64111 to perform a configuration or special cycle on the pci bus. 0x000 bits field name function initial value
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 110 revision 1.0 17.14 interrupts interrupt cause, offset: 0xc18 (all bits are cleared by writing a value of 0 by the cpu/ local master or pci, unless stated otherwise) bits field name function initial value 0 intsum interrupt summary. logical or of all the interrupt bits, regardless of the mask registers values. 0x0 read only 1 memout asserts when the cpu/local master or pci accesses an address out of range in the device decoders or a burst access to 8-/16-bit devices. 0x0 2 dmaout asserts when the dma accesses an address out of range. 0x0 3 cpu/local master- out asserts when the cpu/local master accesses an address out of the cpu/local master decode. 0x0 4 dma0comp asserts at completion of dma channel 0 transfer. 0x0 5 dma1comp asserts at completion of dma channel 1 transfer. 0x0 6 dma2comp asserts at completion of dma channel 2 transfer. 0x0 7 dma3comp asserts at completion of dma channel 3 transfer. 0x0 8 t0exp asserts when timer 0 expires. 0x0 9 t1exp asserts when timer 1 expires. 0x0 10 t2exp asserts when timer 2 expires. 0x0 11 t3exp asserts when timer 3 expires. 0x0 12 masrderr asserts when the GT-64111 detects a parity error dur- ing a master read operation. 0x0 13 slvwrerr asserts when the GT-64111 detects a parity error dur- ing a slave write operation. 0x0 14 maswrerr asserts when the GT-64111 detects a parity error dur- ing a master write operation. 0x0 15 slvrderr asserts when the GT-64111 detects a parity error dur- ing a slave read operation. 0x0 16 addrerr asserts when the GT-64111 detects a parity error on the address lines. 0x0 17 memerr asserts when a memory parity error is detected. applicable only when an external parity checking device is used. 0x0 18 masabort asserts upon master abort. 0x0 19 tarabort asserts upon target abort. 0x0 20 retryctr asserts when the retry counter expires. 0x0 25:21 cpu/local master- int these bits are set by the cpu/local master by writing 0 to generate an interrupt on the pci bus. they are cleared when the pci writes 0. 0x0 29:26 pciint these bits are set by the pci by writing 0 to generate an interrupt on the cpu/local master. they are cleared when the cpu/local master writes 0. 0x0
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 cpu/local master mask, offset: 0xc1c pci mask, offset: 0xc24 30 cpu/local master- intsum interrupt summary. logical or of bits[29:26,20:1], masked by bits[29:26,20:1] of the cpu/local master mask register. 0x0 31 pciintsum interrupt summary. logical or of bits[25:1], masked by bits[25:1] of the pci mask register. 0x0 bits field name function initial value 31:0 cpu/local master- mask mask to the cpu/local master interrupt line for the appropriate bits in the interrupt cause register. bits 0, 25:21, 31:30 are read-only 0. 0 - mask interrupt 1 - do not mask interrupt 0x00000000 bits field name function initial value 31:0 pcimask mask to the pci interrupt line for the appropriate bits in the interrupt cause register. bits 0, 31:26 are read- only 0. 0 - mask interrupt 1 - do not mask interrupt 0x00000000 bits field name function initial value
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 112 revision 1.0 17.15 pci configuration registers device and vendor id, offset: 0x000 status and command, offset: 0x004 bits field name function initial value 31:16 devid provides the unique GT-64111 id number (0x146). 0x4146 15:0 venid provides the manufacturer of the GT-64111 (0x11ab). 0x11ab bits field name function initial value 0 ioen controls the GT-64111s response to i/o accesses. 0 - disable 1 - enable 0x0 1 memen controls the GT-64111s response to memory accesses. 0 - disable 1 - enable 0x0 2 masen controls the GT-64111s ability to act as a master on the pci bus. 0 - disable 1 - enable 0x0 3 reserved 0x0 4 memwrinv controls the GT-64111s ability to generate memory write & invalidate command on the pci bus. 0 - disable 1 - enable 0x0 5 reserved 0x0 6 perren controls the GT-64111s ability to respond to parity errors on the pci by asserting the perr* pin. 0 - disable 1 - enable 0x0 7 reserved 0x0 8 serren controls the GT-64111s ability to assert the serr* pin. 0 - disable 1 - enable 0x0 21:9 reserved 0x0 22 66mhzen 66mhz capable (GT-64111 pci interface is capable of running at 66mhz regardless of this bit value). sampled at reset via pin 15 23 tarfastbb read only bit. indicates that the GT-64111 is capable of accepting fast back-to-back transactions on the pci bus. 0x1 24 datapardet this bit is set by the GT-64111 when it detects a data parity error during master operation. 0x0 27:25 devseltim these pins indicate the GT-64111 s devsel timing (medium), per the pci standard. 0x1 read only 28 tarabort this bit is set upon target abort. 0x0 29 masabort this pin is set upon master abort. 0x0
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 class code and revision id, offset: 0x008 1 bist, header type, latency timer, cache line, offset: 0x00c the bist field is reserved and is hardwired to 0. device and vendor id (0x000), class code and revision id (0x008), and header t y pe (0x00e) fields are read y onl y from the pci bus. these fields can be modified and read via the cpu/local master bus. for more information on these fields, please refer to the pci specification. ras[1:0] base address, offset: 0x010 1. revid does not start at 0x01 in order to leave space for future frevs of the gt-64011 1. the GT-64111 class code is different than in the gt-64011. please see the pci section for details. 30 s y serr this pin is set upon s y stem error. 0x0 31 detparerr this pin is set upon detection of parit y error (in both, master and slave operations). 0x0 bits field name function initial value 7:0 revid indicates the GT-64111 revision number. GT-64111-p-0 = 0x10 1 0x10 15:8 reserved 0x0 23:16 subclass indicates the GT-64111 subclass (0x80 - other mem- or y controller) 0x80 31:24 baseclass indicates the GT-64111 base class (0x5 - memor y controller). 0x05 bits field name function initial value 7:0 cacheline specifies the GT-64111s cache line size 0x00 15:8 lattimer specifies in units of pci bus clocks the value of the latenc y timer of the GT-64111. 0x00 23:16 headt y pe specifies the la y out of b y tes 10h throu g h 3fh. 0x00 31:24 bist built in self test, reserved 0x00 bits field name function initial value 2:0 reserved 0x0 3 prefetch read only 0x1 11:4 reserved 0x0 31:12 base defines the address assi g nment of ras[1:0] (see ras[1:0] bank size 0x00000 bits field name function initial value
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 114 revision 1.0 ras[3:2] base address, offset: 0x014 cs[2:0] base address, offset: 0x018 cs[3] and boot cs base address, offset: 0x01c internal registers memory mapped base address, offset: 0x020 internal registers i/o mapped base address, offset: 0x024 bits field name function initial value 2:0 reserved 0x0 3 prefetch read only 0x1 11:4 reserved 0x0 31:12 base defines the address assignment of ras[3:2] (see ras[3:2] bank size). 0x01000 bits field name function initial value 2:0 reserved 0x0 3 prefetch read only 0x1 11:4 reserved 0x0 31:12 base defines the address assigment of cs[2:0] (see cs[2:0] bank size). 0x1c000 bits field name function initial value 2:0 reserved 0x0 3 prefetch read only 0x1 11:4 reserved 0x0 31:12 base defines the address assignment of cs[3] and boot cs (see cs[3] and boot cs bank size). 0x1f000 bits field name function initial value 11:0 reserved 0x0 31:12 memmapbase defines the address assignment of the GT-64111s internal registers. 0x14000 bits field name function initial value 11:0 reserved 0x0 31:12 iomapbase defines the address assignment of the GT-64111s internal registers. 0x14000
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 board/system device and vendor id, offset: 0x02c expansion rom base address register, offset: 0x030 interrupt pin and line, offset: 0x03c 17.15.1 function 1 configuration registers these registers can only be accessed by specifying function 1 during pci configuration cycles. function 1 ras[1:0] swapped base address, offset: 0x010 bits field name function initial value 15:0 venid provides the unique board/system id number. 0x0 31:16 devid provides the unique board/system id number. 0x0 bits field name function initial value 0 erdecen expansion rom decode enable 0 - disable 1 - enable 0x0 11:1 reserved 0x0 31:12 erbase defines the address of the expansion rom memory space region assigned to the GT-64111. this is where the expansion rom code will appear in system memory when bit 0 of this register contains a value of 1 and bit 1 of this devices command register con- tains a value of 1. 0x1f000 bits field name function initial value 7:0 intline provides interrupt line routing information. 0x00 15:8 intpin indicates which interrupt pin is used by the GT-64111. the GT-64111 uses inta. 0x01 31:16 reserved 0x0 bits field name function initial value 2:0 reserved 0x0 3 prefetch read only 0x1 11:4 reserved 0x0 31:12 base defines the address assignment of swapped ras[1:0] (see ras[1:0] bank size). 0x0000
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 116 revision 1.0 function 1 ras[3:2] swapped base address, offset: 0x014 function 1 cs[3] and boot cs swapped base address, offset: 0x01c for more information on these fields, please refer to the pci specification. bits field name function initial value 2:0 reserved 0x0 3 prefetch read only 0x1 11:4 reserved 0x0 31:12 base defines the address assignment of swapped ras[3:2] (see ras[3:2] bank size). 0x01000 bits field name function initial value 2:0 reserved 0x0 3 prefetch read only 0x1 11:4 reserved 0x0 31:12 base defines the address assignment of swapped cs[3] and boot cs (see cs[3] and boot cs bank size). 0x1f000
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 18. pinout table, 208 pin pqfp (sorted by number) pin # signal name pin # signal name pin # signal name 1 vdd 36 pad[15] 71 syscmd[1] 2 pad[27] 37 pad[14] 72 syscmd[0] 3 pad[26] 38 vss 73 sysad[0] 4 pad[25] 39 pad[13] 74 sysad[1] 5 pad[24] 40 pad[12] 75 sysad[2] 6 cbe[3]* 41 pad[11] 76 sysad[3] 7 idsel 42 pad[10] 77 sysad[4] 8 vss 43 pad[9] 78 sysad[5] 9 vdd 44 vss 79 vss 10 pad[23] 45 vdd 80 vio 11 pad[22] 46 pad[8] 81 vdd 12 pad[21] 47 cbe[0]* 82 sysad[6] 13 pad[20] 48 pad[7] 83 sysad[7] 14 pad[19] 49 pad[6] 84 sysad[8] 15 vss 50 pad[5] 85 sysad[9] 16 vdd 51 vss 86 sysad[10] 17 vss 52 vdd 87 sysad[11] 18 pad[18] 53 pad[4] 88 sysad[12] 19 pad[17] 54 pad[3] 89 sysad[13] 20 pad[16] 55 pad[2] 90 vss 21 cbe[2]* 56 pad[1] 91 tclk 22 frame* 57 pad[0] 92 vdd 23 vss 58 vss 93 sysad[14] 24 vdd 59 must be pulled to vdd 1 94 sysad[15] 25 irdy* 60 dmareq[3]* 95 sysad[16] 26 trdy* 61 interrupt* 96 sysad[17] 27 devsel* 62 syscmd[8] 97 sysad[18] 28 stop* 63 syscmd[7] 98 vss 29 lock* 64 syscmd[6] 99 vdd 30 perr* 65 syscmd[5] 100 sysad[19] 31 vss 66 syscmd[4] 101 sysad[20] 32 vdd 67 vss 102 sysad[21] 33 serr* 68 vdd 103 sysad[22] 34 par 69 syscmd[3] 104 sysad[23] 35 cbe[1]* 70 syscmd[2] 105 sysad[24]
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 118 revision 1.0 1. pin 59 must not be tied directly to vdd. it must be pulled up to vdd through a resistor (galileo recommends 4.7kohm). 106 sysad[25] 141 ad[23] 176 ocas[2]* 107 sysad[26] 142 ad[22] 177 ocas[1]* 108 sysad[27] 143 vss 178 ocas[0]* 109 sysad[28] 144 vdd 179 ras[3]* 110 vss 145 ad[21] 180 ras[2]* 111 vdd 146 ad[20] 181 ras[1]* 112 sysad[29] 147 ad[19] 182 ras[0]* 113 sysad[30] 148 ad[18] 183 dadr[11]/ads* 114 sysad[31] 149 ad[17] 184 dadr[10]/owr[3]* 115 validout* 150 ad[16] 185 vss 116 validin* 151 ad[15] 186 dadr[9]/owr[2]* 117 wrrdy* 152 ad[14] 187 dadr[8]/owr[1]* 118 release* 153 ad[13] 188 dadr[7]/owr[0]* 119 dmareq[0]*/ready* 154 vss 189 dadr[6]/ewr[3]* 120 dmareq[1]*/parerr* 155 ad[12] 190 dadr[5]/ewr[2]* 121 leadre/dmareq[2]* 156 ad[11] 191 dadr[4]/ewr[1]* 122 leadro 157 ad[10] 192 dadr[3]/ewr[0]* 123 oeb 158 ad[9] 193 dadr[2]/badr[2] 124 oee* 159 ad[8] 194 dadr[1]/badr[1] 125 oeo* 160 ad[7] 195 dadr[0]/badr[0] 126 vss 161 ad[6] 196 int* 127 lee 162 ad[5] 197 rst* 128 leo 163 ad[4] 198 vdd 129 ale 164 ad[3] 199 pclk 130 cstiming* 165 vss 200 vss 131 ad[31]/cs[3]* 166 ad[2] 201 gnt* 132 ad[30]/cs[2]* 167 ad[1]/devrw* 202 req* 133 ad[29]/cs[1]* 168 ad[0]/bootcs* 203 vss 134 ad[28]/cs[0]* 169 dwr* 204 pad[31] 135 ad[27]/dmaack[3]* 170 ecas[3]* 205 pad[30] 136 ad[26]/dmaack[2]* 171 ecas[2]* 206 pad[29] 137 ad[25]/dmaack[1]* 172 ecas[1]* 207 pad[28] 138 vss 173 ecas[0]* 208 vss 139 vdd 174 vdd 140 ad[24]/dmaack[0]* 175 ocas[3]* pin # signal name pin # signal name pin # signal name
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 19. dc characteristics - preliminary/subject to change 19.1 absolute maximum ratings 19.2 recommended operating conditions 19.3 dc electrical characteristics over operating range (tc=0-70 o c; vdd=+3.3v, +/-5%) symbol parameter min. max. unit vdd supply voltage -0.3 4 v vi input voltage -0.3 5.5 v vo output voltage -0.3 vdd+0.3 v io output current 24 ma iik input protect diode current +-20 ma iok output protect diode current +-20 ma tc operating case temperature 0 105 c tstg storage temperature -40 125 c esd 2000 v symbol parameter min. typ. max. unit vdd supply voltage 3.15 3.3 3.45 v vi input voltage (peripheral @ 3.3v) 0 3.45 v vi input voltage (peripheral @ 5.0v) 0 5.25 vo output voltage 0 vdd v tc operating case temperature 0 70 c cin input capacitance 7.2 pf cout output capacitance 7.2 pf symbol parameter test condition min. typ. max. unit vih input high level guaranteed logic high level 2.0 vpe- riph- eral + 0.5 v vil input low level guaranteed logic low level -0.5 0.8 v
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 120 revision 1.0 voh output high voltage: dwr*, dadr[0]/badr[0], dadr[1]/badr[1], dadr[2]/ badr[2], dadr[3]/ewr[0]*, dadr[6:4]/ewr[3:1]*, dadr[10:7]/owr[3:0]*, dadr[11]/ads*, ras[3:0]*, ecas[3:0]*, ocas[3:0]*, ad[31:28]/ cs[3:0]*, ad[27:24]/ dmaack[3:0]*, ad[23:2], output high voltage: ad[1]/devrw*, ad[0]/ bootcs*, cstiming*, ale, leo, lee, oeo*, oee*, oeb, leadro, leadre/dmareq[2]* ioh = 16 ma 2.4 v voh output high voltage: sysad[31:0], syscmd[8:0], wrrdy*, validin* ioh = 12 ma 2.4 v voh output high voltage: interrupt* ioh = 8 ma 2.4 v vol output low voltage: dwr*, dadr[0]/badr[0], dadr[1]/badr[1], dadr[2]/ badr[2], dadr[3]/ewr[0]*, dadr[6:4]/ewr[3:1]*, dadr[10:7]/owr[3:0]*, dadr[11]/ads*, ras[3:0]*, ecas[3:0]*, ocas[3:0]*, ad[31:28]/ cs[3:0]*, ad[27:24]/ dmaack[3:0]*, ad[23:2], ad[1]/devrw*, ad[0]/ bootcs*, cstiming*, ale, leo, lee, oeo*, oee*, oeb, leadro, leadre/dmareq[2]* iol = 16 ma 0.4 v vol output high voltage: sysad[31:0], syscmd[8:0], wrrdy*, validin* iol = 12 ma 0.4 v vol output low voltage: interrupt* iol = 8 ma 0.4 v iih input high current +-1 ua iil input low current +-1 ua iozh high impedance output current +-1 ua iozl high impedance output current +-1 ua symbol parameter test condition min. typ. max. unit
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 19.4 thermal data table 30 shows the package thermal data for the GT-64111. please check with galileo if you are in doubt as to thermal considerations for your system. vh input hysteresis tbd tbd tbd mv icc operating current vcc=3.45v, f = 66mhz 200 ma table 30: 208 pqfp thermal data parameter definition value q jc thermal resistance: junction to case, 0 m/s airflow 12 c/w q ca thermal resistance: case to ambient 0 m/s airflow 1 m/s airflow 2 m/s airflow 18.1 c/w 16.5 c/w 15.1 c/w symbol parameter test condition min. typ. max. unit
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 122 revision 1.0 20. ac timing - targets/subject to change (tcase= 0-70 o c; vdd= +3.3v, +/- 5%) symbol signals description min max unit t1 tclk pulse width high 6 ns t2 tclk pulse width low 6 ns t3 tclk clock period 15 30 ns t4 tclk rise time 2.5 ns t5 tclk fall time 2.5 ns t6 rst* active 10 tclk t7 dmareq[3]*, leadre/ dmareq[2]*, dmareq[1]*/parerr*, ad[31:0], dmareq[0]*/ ready* setup (as dmareq[0]*) 5 ns t8 dmareq[0]*/ready*, setup (as ready*) 7 ns t9 wrrdy*, validin*, sysad[31:0], syscmd[8:0], interrupt* delay 29ns t10 dadr[11:0] delay (row address) 3 15 ns t11 dadr[11:0] delay (column address) 2 11 ns t12 badr[2:0], ads* delay 2 10 ns t13 ewr[3:0]*, owr[3:0]* delay from tclk falling edge 2 8 ns t14 dwr*, cstiming*, ale, delay 2 8 ns t15 ecas[3:0]*, ocas[3:0]*, oeb, oeo*, oee*, ad[31:0] delay 28ns t16 ale, leo, lee delay from tclk falling edge 2 9 ns t17 validout*, release*, dmareq[3]*, leadre/ dmareq[2]*, dmareq[1]*/parerr*, sysad[31:0], syscmd[8:0], ad[31:0], dmareq[0]*/ready* hold 1 ns t18 validout*, release*,sysad[31:0], syscmd[8:0] setup 3 ns
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 table 31. pci signals notes: 1. all delays, setup, and hold times are referred to tclk rising edge, unless stated otherwise. 2. all outputs are specified for 50pf load except: wrrdy*, validin*, ale, leadro, leadre/dmareq[2]* - 30pf, inter- rupt* - 20 pf. 20.1 tclk/pclk restrictions the tclk frequency must be greater than pclk by at least 1 mhz (f tclk > f pclk + 1 mhz). this restriction applies to all sync modes. there is one exception to this restriction. if f tclk = f pclk and the two clocks are synchronized (derived from the same clock generator), a minimum skew of 5.5ns must be observed between rising edge of tclk and pclk, as shown in fig- ure 26. galileo recommends using an inverted tclk as pclk in order to guarrantee this skew. t19 leadre/dmareq[2]*, leadro delay 29ns t20 leadre/dmareq[2]*, leadro delay from tclk falling edge 2 9 ns t21 leo, lee delay 2 8 ns t22 ras[3:0]* delay 3 8 ns symbol signals description min max unit pclk clock period 15 ns pad[31:0], frame*, irdy*, trdy*, devsel*, gnt* setup 4 ns cbe[3:0], par, stop*, lock*, idsel, perr* setup 3 ns pad[31:0], cbe[3:0]*, par, frame*, irdy*, trdy*, stop*, lock*, idsel*, devsel*, gnt*, perr* hold 0 ns pad[31:0], cbe[3:0], par, frame*, irdy*, trdy*, stop*, devsel*, req*, perr*, serr*, int* output delay 2 7 ns
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 124 revision 1.0 figure 26: tclk = pclk skew requirement in addition to the above restriction, there are few sync modes specific restrictions, summarized in table 32. the sync mode can be programed by the cpu, the pci or during autoload. for sync mode information, see section 17.13. table 32. tclk/pclk restrictions sync mode pclk frequency range restrictions 0 from dc up to tclk t pclk > t tclk + 1.5ns, unless running with tclk = pclk synchronized. 1 from tclk/2 up to tclk f pclk > f tclk /2 + 1 mhz, unless running with synchro- nized f pclk = f tclk /2 and minimum skew of 5.5ns between pclk rise and every second tclk rise is guarranteed. 2 from tclk/2 up to tclk tclk and pclk are synchronized. f pclk = f tclk /2 is allowed only if a minimum skew of 5.5ns between pclk rise and every second tclk rise is guarranteed. tclk pclk tclk to pclk 5.5ns minimum skew pclk to tclk 5.5ns minimum skew
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 figure 27: tclk and reset timing waveform t6 0ns 100ns 200ns rst* tclk reset t4 t5 t1 t2 t3 tclk 0ns 50ns tclk
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 126 revision 1.0 figure 28: block write to dram, castoraswr = 1, caswr = 0 cmd addr do d1 d2 d3 d4 d5 d6 d7 d0 d1 d2 d3 d4 d5 d6 d7 row address column address 0 1 2 3 4 5 6 7 t18 t17 t7 t11 t11 t12 t14 t22 t22 t15 t15 t21 t16 tclk validout* release* syscmd sysad validin* wrrdy* ad dadr badr dwr* ras* ecas*, ocas* lee, leo oee*, oeo*
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 figure 29: blcok read from 32-bit device, acctofirst = 3, acctonext = 3 cmd addr d0 d1 d2 d3 d4 d5 d6 d7 addr d0 d1 d2 d3 d4 d5 d6 d7 0 1 2 3 4 5 6 7 d0 d1 d2 d3 d4 d5 d6 d7 t18 t17 t9 t9 t9 t9 t9 t14 t16 t12 t12 t15 t12 t14 t21 t16 t15 t15 tclk validout* release* syscmd sysad validin* wrrdy* ale ads ad badr devrw* cs* cstiming* ewr*, owr* lee, leo oee*, oeo* device data
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 128 revision 1.0 21. functional waveforms functional waveforms are not included in this datasheet. transcribing waveforms from simulator outputs to real world documentation is extremely error prone and we do not currently have a tool that can do it effectively. rather than risk introducing errors, galileo technology provides a seperate electronic document that included several dozen functional waveforms. the waveform summary is available on our website: www.galileot.com (look in the library area). hard- copies can also be ordered by contacting us at 408-451-1400.
GT-64111 system controller for rc4640, rm523x and vr4300 cpus revision 1.0 22. packaging figure 30: 208 lead pqfp package outline table 33: 208 pqfp package dimensions millimeters symbol min. nom. max. a 1 0.05 0.25 0.50 a 2 3.17 3.32 3.47 b 0.10 0.20 0.30 c 0.10 0.15 0.20 d 27.90 28.00 28.10 e 27.90 28.00 28.10 e0.50 hd 30.35 30.60 30.85 he 30.35 30.60 30.85 l 0.45 0.60 0.75 l 1 1.30 y0.08 q0 7 a 1 he e hd d b a 2 l l 1 0.08(0.003) m y e c
GT-64111 system controller for rc4640, rm523x and vr4300 cpus 130 revision 1.0 23. revision history table 34: document history document type rev. number date comments product review 0.9 1/19/98 first release, based on rev 1.3 gt-64011 spec. product review 1.0 3/24/98 second release. data sheet 1.1 feb 4, 1999 1. add tclk/pclk ratio restriction, section 20.1. 2. cpu restrictions, section 3.8. 3. pci parity support, section 6.6. 4. correct device parameter regs initial values, section 17.8. 5. add pci sync modes clarification, section 17.13. 6. add 66mhz capable bit, section 6.8 section 17.15. 7 icc specification, section 19.3. 8. thermal data, section 19.4. 9. pci ac timing update. minimum setup require- ment change from 3ns to 4ns on pad[31:0], frame*, irdy*, trdy*, devsel*, gnt*. all output delays changed from 6ns to 7ns, section 20.

▲Up To Search▲

Price & Availability of GT-64111

	To Download GT-64111 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .